Über die Connectoren kann Verbindung zum Tomcat aufbauen. Über den HTTP-Connector kann man, wie der Name schon sagt HTTP-Verbindungen aufbauen. Also der Port über den alle Webseiten ausgeliefert werden. Bei Tomcat ist dies defaultmäßig immer “8080“. Im Gegensatz zu Port “80“, welcher z.B. bei Apache2 genommen wird. Dies ist so, da Tomcat selten direkt als Webserver auftritt. Meist sind ihm immer noch Webserver vorgeschalten. Zum Beispiel Nginx per Reverse Proxy oder Apache2. Dieser verbindet sich meist über mod_jk. Damit kämen wir dann zum AJP-Connector. Dieser wird also zur kommunikation zwischen dem Apache2 Modul mod_jk und Tomcat benutzt. Das Protokoll ist ein binäres, es wird also kein HTTP gesprochen. Von jedem Connector kann es immer mehrere geben, jeweils natürlich mit unterschiedlichen Ports.

Die „server.xml“ ist im XML Stil ausgebaut. Alles wird mit Tags definiert. Alles umschließt das „<server>“-Tag. Innerhalb davon sind dann immer einige Listener und Resourcen definiert. Im weiteren Verlauf kommt dann das „<service>“-Tag. Darin enthalten sind die Connectoren für HTTP und AJP. Weiterhin noch das „<engine>“-Tag. Damit kann man den Standardhost für den Tomcat angeben, welcher genommen werden soll, wenn kein anderer passt. Darin enthalten ist dann einmal das Realm-Tag und dann noch das besagte „<host>“-Tag. Dieses entspricht grob den Vhosts beim Apache2-Webserver. Damit kann man Hostnames auf Applikationen mappen. Die „appBase“ (DocumentRoot) festlegen und weitere Feature zur Behandlung von Sourcecode. Innerhalb hiervon kann man wiederum „<context>“-Tags festlegen, welche dann die Applikationen noch genauer beschreiben und auch Domain-Pfade kennen. Und letztendlich kann man jetzt wieder „<resource>“-Tags anlegen, um der Applikation z.B. feste Datenbankverbindungen mitzugeben.

Applikationen kann man hier definieren, muss man aber nicht. Eine wesentlich dynamischere Variante wäre hier, die “context.xml” zu benutzten. Denn bei Änderungen an der server.xml muss danach der Tomcat neu gestartet werden. Benutzt man die “context.xml” braucht es zum einspielen keinen Neustart.

Baumansicht der Verzeichnisstruktur eines Tomcat 5.5

|– bin
|– common
| |– classes
| |– endorsed
| |– i18n
| `– lib
|– conf
|– logs
|– server
| |– classes
| |– lib
| `– webapps
| |– host-manager
| `– manager
|– shared
| |– classes
| `– lib
|– temp
|– webapps
| `– AG_Public
`– work
`– Catalina

Das Lib-Verzeichnis

Unterhalt „common“ liegt das Verzeichnis für die ganzen Libaries die Tomcat-weit genutzt werden können. Auf diese Libs haben alle Applikationen zugriff.

Das Konfigurationsverzeichnis „conf“

Hier liegen alle Dateien die Konfiguration betreffend. Wichtig sind hier die „server.xml“ und die „web.xml“. Will man die einfache HTTP-Auth von Tomcat nutzen, ist dann noch die „tomcat-users.xml“. Es gibt weiterhin noch eine weitere wichtige Konfig die aber im „bin“-Verzeichnis liegt. Das ist die „catalina.sh“. Hier kann man noch Startoptionen für die Tomcat-JVM einstellen. Z.B. Heapsize oder GarbageCollector.

Das WebApp-Verzeichnis

Hie liegt die eigentlich Applikation. Entweder als Verzeichnis oder als WAR-Datei. Es kann auch beides nebeneinander liegen, aber auch nur eins von beiden vorhanden sein. dies obliegt den Einstellungen in der „server.xml“. Wenn beides vorhanden ist, ist es meist auch so, das wenn man das WAR löscht, auch das Verzeichnis vom Tomcat selbst entfernt wird.

Das „work“-Verzeichnis

Hier lagert der Tomcat die ganzen compilierten Klassen, Servlets und JSP. Dabei wird alles im Unterordner „Catalina“ gespeichert. Hier wiederum wird das ganze noch nach Hosts aufgeteilt. In der Regel sollte bei einer Applikation, dann auch nur ein Verzeichnis mit Namen „localhost“ da sein. Hat man in der „server.xml“ mehrere Hosts definiert, findet man die hier alle wieder. Wenn man die Vermutung hat, das der Tomcat die neuen Sourcen, welche man gerade eingespielt hat, noch nicht übernommen hat, dann sollte man den Tomcat einmal stoppen, das „work“-Verzeichnis leeren und ihn dann wieder starten. Dann ist er gezwungen alles noch mal neu zu compilieren.

Einen LoadBalancer richtet man ebenso einfach ein. Zuerst braucht man aber mindestens einen Worker und damit es Sinn macht am besten gleich einen 2. dazu. Den Balancer kann man frei benennen. Mit „worker.TestBalancer.balance_workers“ legt man fest, welche Worker Teil des Balancer sind. Dort Komma- separiert die Liste an Tomats mit ihren Worker-Namen eintragen. „worker.TestBalancer.type“ setzt man dann auf „lb“. Wenn man in seiner Webapplikation mit Seesions arbeitet sollte man dann noch „worker.adminbalancer.sticky_session“ auf „1“ setzten. Damit man immer auf dem selben Worker bleibt und nicht mit jeden Request hin und her springt. Für die „method“ gibt es dann mehrere Optionen, hier ein Auszug aus der offiziellen Doku(1):

• If method is set to R[equest] the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.
• If method is set to S[ession] the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.
• If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.
• If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.

Request und Session haben sich bis jetzt bewährt. Der gesamte Parameter wird dann wieder mit „worker.TestBalancer.method“ gesetzt. Damit wäre dann auch ein Balancer konfiguriert. diesen dann nur noch in der „worker.list“ mit seinen Namen hinzufügen.

(1): http://tomcat.apache.org/connectors-doc/reference/workers.html

private void doAction() throws IllegalStateException, IOException, AuthenticationFailedException, TimeoutException
{
OriginateAction originateAction;
ManagerResponse originateResponse;

originateAction = new OriginateAction();

if (sSipServer != null)
{
log.info(“OriginateTo: ” + sCallMethod + “/” + sCallerNumber + “@” + sSipServer);
originateAction.setChannel(sCallMethod + “/” + sCallerNumber + “@” + sSipServer);
}
else
{
log.info(“OriginateTo: ” + sCallMethod + “/” + sCallerNumber);
originateAction.setChannel(sCallMethod + “/” + sCallerNumber);
}
originateAction.setContext(sContext);
originateAction.setExten(sCalleeNumber);
originateAction.setPriority(iPriority);
originateAction.setTimeout(iTimeOut);
originateAction.setAsync(true);

// connect to Asterisk and log in
managerConnection.login();

// send the originate action and wait for a maximum of 30 seconds for Asterisk
// to send a reply
originateResponse = managerConnection.sendAction(originateAction, 30000);

// print out whether the originate succeeded or not
log.info(“originateResponse: ” + originateResponse.getResponse());

// and finally log off and disconnect
managerConnection.logoff();
}

EDIT: Hat sich alles erledigt, ich hatte nur eine Variable falsch gesetzt << … damn Millisekunden … ^^

Hat man mal ein dynamisches Webprojekt in Eclipse mit Tomcat 6 angelegt und will nun zurück auf Tomcat 5.5, kann das scheinbar nicht ganz so einfach sein. Will man nämlich in den Projekt Facets einfach die Dynamic Web Modul API von 2.5 auf 2.4 ändern, geht dies nicht. Man kann es zwar auswählen, doch nicht bestätigen, da Eclipse die Übernahme der Optionen verweigert.

Doch lässt sich dies ganz einfach Lösen. Einfach nicht den Einstellungs-Dialog von Eclipse nutzen und schon wird alles ganz einfach. In Eclipse einfach den Navigator-View auf machen und im betroffenen Projekt den Ordner “.settings” öffnen. Hier finden wir nun einiges Konfigurationsdateien, die zwar ganz nett sind, die Interessante ist aber “org.eclipse.wst.common.project.facet.core.xml“. Diese öffnen wir und ändern dort einfach den Parameter “<installed facet=”jst.web” version=”2.5″/>“. Hier nur die 2.5 gegen 2.4 austauschen, speichern und fertig. Und schon haben wir unsere Servlet API geändert. Jetzt sollte das Projekt auch wieder im Tomcat 5.5 laufen.

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Danach hat man erstmal grob Zugang zum Tomcat. Natürlich sollte man das noch mit SSL und nem Passwort absichern. Doch ich wollte erstmal die grundsätzliche Funktionalität Testen. Doch jegliche Versuche damit schlugen fehl. Ersteinmal sei auch gesagt, dass ein “export” davor muss und kein “set“, wie manche schreiben. Bei einer normalen Tomcat Installation ist es damit dann auch schon getan. Doch bei Gentoo muss das ganze nicht in die catalina.sh eingetragen. Trägt man es dort ein, wird es schlicht und einfach ignoriert. Also wohin nun damit? Für den an Gentoo gewöhnten Admin ist es klar das das nach “/etc/conf.d/tomcat-5.5” muss, für einen Debian/Ubuntu Admin ist dies allerdings nicht ganz so klar. Und auch Google verschwieg mir dies Information. Ich hatte mich dann nur daran erinnert das neulich beim Apache ähnlich schritte vollführt werden mussten. Da war es dann auf einmal auch ganz logisch, das dies beim Tomcat ähnlich sein würde. Doch darauf kam ich erst nach einer deprimierenden Suche und vielen im Nachhinein unnötigen Test.

In die “/etc/conf.d/tomcat-5.5” muss nun eben das ganze ohne “export” am Anfang eingetragen werden. Wenn man in der Datei ein wenig nach unten geht, findet man auch schon eine dafür vorbereitet Stelle, um die Daten dort einzufügen. Natürlich können sie innerhalb der Datei überall stehen, doch ein wenig Ordnung schadet ja auch nicht. Also hab ich dann dort Folgendes eingefügt:

export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \

Nachdem ich also alles in “/etc/conf.d/tomcat-5.5” eingetragen hatte, den Tomcat zum X. mal neu gestartet hatte, konnte ich mich nun endlich per jconsole auf diesen verbinden und mir das innere der JVM ansehen.

<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />

Und damit wären wir auch schon fertig! Jetzt wird beim kompilieren mit dem “javac task” immer ECJ genommen anstatt der Compiler des System-JDK.

Und wenn man mal “fehlerhafte” Klassen kompilieren will, kann man jetzt das “javac Flag” “failonerror” auf “off” setzten. Anders als der Standard Java Compiler, welcher den build-Prozess dann zwar als erfolgreich markiert, aber nichts macht, kompiliert ECJ auch fehlerhafte Klassen. Also zum Beispiel Klassen wo wiederum andere Klassen importiert werden, welche aber nicht im “Classpath” stehen. Denn ECJ bietet das Feature “proceedOnError”, welche durch ”failonerror=off” gesetzt wird.

<javac failonerror="off"> blubb </javac>

Doch ein wenig versteckt biete Sun alle seine Versionen doch noch an. Es gibt sogar ein nettes Interface was einem dies leicht zugänglich macht:  Das SUN Java Archive