ubuntuusers.de

Hallo miteinander

Ich wollte mir mal eben schnell meine Tomcat-Enwicklungsumgebung aufspielen und mit dem Packetmanager sollte das ja nicht all zu schwer sein. Hab zusätzlich noch den Wiki-Artikel hier bemüht aber so ganz will das Ding nicht und verstehen tu ich es schon gar nicht.

Warum zur Hölle (entschuldigt die Ausdrucksweise) gibt es zig verschiedene webapps-Verzeichnisse? Hier mal eine kleine Auswahl (kann sein dass es nicht 100% stimmt, bin grad mit XP unterwegs)

• /var/lib/tomcat5.5/webapps (meiner Vorstellung nach das einzige richtige Verzeichnis)

• /usr/share/tomcat5.5-webapps

• /usr/share/tomcat5.5/webapps

• /usr/share/tomcat5.5/server/webapps
  ??? Ich kapiers nicht ???
  Gut, einige sind wahrscheinlich symbolische links, aber wozu das Ganze? Hat das was mit irgendwelchen Berechtigungen zu tun?

Die Beispielanwendungen kann ich beispielsweise aufrufen, aber ich möchte/muss die ROOT-Anwendung austauschen. In welches dieser Verzeichnisse muss denn nun mein in ROOT.war umbenannten Archiv kopiert werden? Hab vorher natürlich sämtliche webapps/ROOT-Verzeichnisse gelöscht.

Ich hoffe einer von euch kann mir das erklären.

Vielen Dank schon mal.

Sorry für das nachhaken, aber hat niemand eine Erklärung dafür?

Ich muss zeitnah mein System wieder ans laufen bringen und möchte das natürlich korrekt tun.

Thx

Hi,
sorry, aber ich kenne das Einbinden von webapps in den Tomcat nur über das Einfügen einer webapp.xml-Datei in de4n Pfad $CATALINA_HOME/conf/Catalina/localhost.

Was war das umbenannte ROOT.war denn vorher? ein .jar?

Ich hab leider im moment nicht viel Zeit mal nachzuschauen wie das mit dem einbinden über die .xml-Dateien genau geht, da ich übermorgen Prüfung habe, deshlab gehe ich jetzt auch schlafen. Gute nacht!

Schmeiss Deinen Tomcat runter.

- Falls noch nicht vorhanden, installier Dir das JDK von Sun, am besten Version 1.6
- Zieh dir die binaries von Apache runter
- leg einen Benutzer "tomcat" mit entspr. home-Verzeichnis an
- ent-tar die Apache-Binaries in das Verzeichnis
- sieh zu, dass ${PATH} einen Verweis auf "java" enthaelt
- sie zu, dass ${JAVA_HOME} auf die gueltige Java-Installation verweist
- wechsle in die ent-tarte Tomcat-Installion
- wechsle dort nach "bin"
- starte Tomcat bin "./startup.sh"
- hab Spass
- stoppe Tomcat aus dem bin-Verzeichnis mit "./shutdown.sh"

Wir haben hier auf der Arbeit Debian-Server laufen, auf meinem privaten Lappi laeuft Gutsy, und die Debian / Ubuntu-Packages fuer Tomcat sind einfach nur Kernschrott.

Ich hab's via Package installiert, dann Tomcat wie oben zusaetzlich installiert & die packages wieder geloescht. Die Start-Scripte unter /etc/init.d bleiben erhalten: Diese auf die neue Location & den Benutzer "tomcat" kurz angepasst, und schon hast Du eine stabile Umgebung.

Mit dem o.a. Verfahren wirst Du unter der neuen Tomcat-Installation genau einen webapps-Folder haben.

Ansonsten schau mal nach, ob es sich bei Deiner Ausgabe von oben evtl. teilweise um Symlinks handelt...

Gruss

Gregor

An eine eigenständige Installation hatte ich auch schon gedacht, aber inzwischen läuft die Sache. Es gab einige Probleme mit der Policy bezüglich des Loggers (konnte ich Hilfe einer Anleitung ausm Netz beheben). Ich wollte halt die Packetinstallation behalten weil ich nicht wirklich der Linux-Kenner bin, sind eher nur Grundkenntnisse vorhanden (insbesondere wenn es um Benutzer, Rechte, und automatische Jobs geht)

Allerdings verstehe ich nicht wieso die Debian/Ubuntu-Packete so "schlecht" sind? Beide Systeme werden nun wirklich nicht selten eingesetzt, da muss es doch eine Art "Best-Practise" geben.

@drvoodooDas ROOT
Das ROOT.war war vorher ein opencms.war 😉
Da ich sonst keine Anwendungen da drauf laufen habe spare ich mir so etwas in der URL

mschlegel hat geschrieben:

Allerdings verstehe ich nicht wieso die Debian/Ubuntu-Packete so "schlecht" sind? Beide Systeme werden nun wirklich nicht selten eingesetzt, da muss es doch eine Art "Best-Practise" geben.

Ohne jetzt einen Flamewar starten zu wollen:

Unter Debian (eigentlich meinem Favourite) versuchen die Maintainer, saemtliche Konfigurationsdateien moeglichst kurz & redundanzfrei zu halten. Prinzipiell ein loeblicher Ansatz, aber manchmal schiessen sie sich dabei auch in's Knie.

Best Practise ist nach meiner Erfahrung die, dass man Tomcat selbst installiert, das JDK ebenfalls, und zwar das von SUN.

Warum?

Weil man an kritische Updates schneller rankommt.

Zusaetzlich legt man noch ein paar nuetzliche Symlinks an

root@Debian-40-etch-64-LAMP:/usr/lib/jvm # ls -l  /usr/lib/java_home
lrwxrwxrwx 1 root root 14 2008-06-05 21:23 /usr/lib/java_home -> java-1.5.0-sun

root@Debian-40-etch-64-LAMP:/home/apps/tomcat # ls -l
total 4
drwxr-xr-x 11 tomcat tomcat 4096 2008-05-23 17:56 apache-tomcat-5.5.26
lrwxrwxrwx  1 tomcat tomcat   20 2008-05-23 17:56 tomcat55 -> apache-tomcat-5.5.26

und dann passt das.

Das hat den Vorteil, dass man z.B. die spezifischen Umgebungsvariablen auf die symbolischen Links zeigen laesst, und wenn man z.B. mal die Version des JDK oder von Tomcat wechseln willt, schiesst man einfach den Link um.

Gruss

Gregor