JDBC + Spring 3.0.0.RELEASE

This maven2 archetype contains a little sample application with the new Spring 3.0.0.RELEASE Framework and JDBC. It is deployed on the PLOIN Repository-Server on

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempSpringJdbc -DarchetypeVersion=1.0 -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/ -DgroupId=org.ploin -DartifactId=demoSpringJdbc

The archetype is prepared for the MySQL database.

Hibernate 3.3.2.GA + Spring 3.0.0.RELEASE

This maven2 archetype contains a little sample application with the new Spring 3.0.0.RELEASE Framework and Hibernate 3.3.2.GA. The configuration is xml-driven. It is deployed on the PLOIN Repository-Server on

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempSpringHibernate -DarchetypeVersion=1.7 -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/ -DgroupId=org.ploin -DartifactId=demoSpringHibernate

The archetype contains the HSQLDB database. After you have created your demoApp, you can run the tests with “mvn test”. If you want switch to another database, like MySQL or Oracle, your have to make some changes in the pom.xml and in the applicationContext.xml

SpringMvc + Spring 3.0.0.RELEASE

This maven2 archetype contains a little sample application with the new Spring 3.0 RC1 Framework and Spring Mvc. It is deployed on the PLOIN Repository-Server on

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempSpringMvc -DarchetypeVersion=1.2 -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/ -DgroupId=de.ploin -DartifactId=demoSpringMvc

IceFaces 1.8.2 + Spring 3.0.4.RELEASE + Hibernate 3.3.4.GA

This maven2 archetype contains a little sample web application with this Frameworks:

  • Spring 3.0.4.RELEASE Framework
  • Servlet-API 2.5
  • MyFaces-Core 1.2.8
  • IceFaces 1.8.2
  • Facelets 1.11
  • ploinFaces 1.4.6
  • ploinMailFactory 1.3.1
  • Hibernate 3.3.4.GA
  • TestNG 5.8
  • Log4J 1.2.15
  • HSQLDB 1.8.0.7

The configuration is xml-driven. It is deployed on the PLOIN Repository-Server

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn  archetype:generate -DarchetypeGroupId=org.ploin.archetype  -DarchetypeArtifactId=tempSpringIceHibernate -DarchetypeVersion=1.1.1  -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/  -DgroupId=org.ploin -DartifactId=demoSpringIceHibernate

The created project is a very simple web-application with a login mask and three xhtml-sites. I have tested the app on a tomcat 6.0.20 and Java 1.6 on Mac OS X Snow Leopard.

You can login with the username “admin” and the password “admin”.

After the creation the app is running with the HypersoniceSQL DBMS. But it is very easy to switch to MySQL or Oracle. I put the drivers for MySQL and Oracle as a comment in the pom.xml. So you just need to comment int the right lines in the pom.xml.

JSF 2.0 Archetype

This maven2 archetype contains a little sample application with the new JavaServer Faces 2.0 (reference implementation from mojarra). It is deployed on the PLOIN Repository-Server on

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate  -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempJsf2  -DarchetypeVersion=1.2  -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/  -DgroupId=de.ploin -DartifactId=demoJsf2

RichFaces 3.3.2.GA + Spring 3.0.0.RELEASE + Hibernate 3.3.0

This maven2 archetype contains a little sample web application with this Frameworks:

  • Spring 3.0.0.RELEASE Framework
  • Servlet-API 2.5
  • MyFaces-Core 1.2.8
  • RichFaces 3.3.2.GA
  • Facelets 1.1.14
  • ploinFaces 1.4.7.8
  • ploinMailFactory 1.4.1
  • Hibernate 3.3.0
  • TestNG 5.8
  • Log4J 1.2.15
  • HSQLDB 1.8.0.7

The configuration is xml-driven. It is deployed on the PLOIN Repository-Server

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn  archetype:generate -DarchetypeGroupId=org.ploin.archetype  -DarchetypeArtifactId=tempSpringRichHibernate -DarchetypeVersion=1.1.1  -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/  -DgroupId=org.ploin -DartifactId=demoSpringRichHibernate

The created project is a very simple web-application with a login mask and 2 xhtml-sites. I have tested the app on a tomcat 6.0.20 and Java 1.6 on Mac OS X Snow Leopard.

You can login with the username “admin” and the password “admin”.

After the creation the app runs with the HypersoniceSQL DBMS. But it is very easy to switch to MySQL or Oracle. I put the drivers for MySQL and Oracle as a comment in the pom.xml. So you just need to comment in the right lines in the pom.xml.

JSF 1.2 Archetype

This maven2 archetype contains a little sample application with JavaServer Faces 1.2 (MyFaces-Core), Facelets 1.1.14 and ploinFaces 1.4.6. It is deployed on the PLOIN Repository-Server on

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate  -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempJsf1.2  -DarchetypeVersion=1.1  -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/  -DgroupId=de.ploin -DartifactId=demoJsf1.2

IceFaces 2.0 ALPHA + Spring 3.0.0.RELEASE + Hibernate 3.3.2.GA

This maven2 archetype contains a little sample web application with this Frameworks:

  • Spring 3.0.0.RELEASE Framework
  • Servlet-API 2.5
  • JSF 2.0 (mojarra 2.0.2)
  • IceFaces 2.0
  • ploinFaces 1.6
  • ploinMailFactory 1.3.1
  • Hibernate 3.3.2.GA
  • TestNG 5.8
  • Log4J 1.2.15
  • HSQLDB 1.8.0.7

The configuration is xml-driven. It is deployed on the PLOIN Repository-Serve

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate  -DarchetypeGroupId=org.ploin.archetype  -DarchetypeArtifactId=tempSpringIceHibernate -DarchetypeVersion=1.4  -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/  -DgroupId=org.ploin -DartifactId=demoSpringIceHibernate

The created project is a very simple web-application with a login mask and three xhtml-sites. I have tested the app on a tomcat 6.0.20 and Java 1.6 on Mac OS X Snow Leopard.

You can login with the username “admin” and the password “admin”.

After the creation the app is running with the HypersoniceSQL DBMS. But it is very easy to switch to MySQL or Oracle. I put the drivers for MySQL and Oracle as a comment in the pom.xml. So you just need to comment int the right lines in the pom.xml.

RichFaces 4.0.0.ALPHA1 + Spring 3.0.0.RELEASE + Hibernate 3.3.0

This maven2 archetype contains a little sample web application with this Frameworks:

  • Spring 3.0.0.RELEASE Framework
  • Servlet-API 2.5
  • JSF 2.0 (mojarra 2.0.2)
  • RichFaces 4.0.0.ALPHA1
  • ploinFaces 1.6
  • ploinMailFactory 1.3.1
  • Hibernate 3.3.0
  • TestNG 5.8
  • Log4J 1.2.15
  • HSQLDB 1.8.0.7

The configuration is annotation-driven. It is deployed on the PLOIN Repository-Serve

http://www.ploin-m2.de/nexus/content/groups/public/

you can create a project from the archetype with the following command:

mvn archetype:generate -DarchetypeGroupId=org.ploin.archetype -DarchetypeArtifactId=tempSpringRichHibernate -DarchetypeVersion=1.7 -DarchetypeRepository=http://www.ploin-m2.de/nexus/content/groups/public/ -DgroupId=org.ploin -DartifactId=demoSpringRichHibernate

The created project is a very simple web-application with a login mask and 2 xhtml-sites. I have tested the app on a tomcat 6.0.20 and Java 1.6 on Mac OS X Snow Leopard.

You can login with the username “admin” and the password “admin”.

After the creation the app is running with the HypersoniceSQL DBMS. But it is very easy to switch to MySQL or Oracle. I put the drivers for MySQL and Oracle as a comment in the pom.xml. So you just need to comment in the right lines in the pom.xml.

jMeter + JSF Trinidad

jMeter eignet sich sehr gut für Stresstests. Dieses HOWTO zeigt wie es möglich ist ein Stresstest für eine JSF-Trinidad-Anwendung mit jMeter aufzunehmen und zu starten. jMeter kann von hier runter geladen werden: http://jakarta.apache.org/jmeter/

Nach dem entpacken muss die “<jMeter>/bin/jmeter.sh” ausgeführt werden. Unter Windows dementsprechend “<jMeter>/bin/jmeter.bat”. Nach dem erfolgreichen Start der Anwendung sollte zu erst eine neue “Thread Group” im Testplan erstellt werden:

In der Thread Group kann eingestellt werden mit wie vielen Usern der Test simuliert werden soll und wie oft.

Als nächstes legen wir ein Config Element “HTTP Requests Defaults” an.

Hier können Angaben zum Server, Port, Protokoll und Ziel-Path gemacht werden.

Da JSF-Trinidad die JSESSIONID in einem Cockie ablegt, fügen wir noch einen “HTTP Cockie Manager” hinzu. Dieser braucht nicht konfiguriert zu werden. Er muss einfach da sein damit es funktioniert.

Beim testen einer JSF Applikation muessen einige Dinge beachtet werden. JSF arbeitet nach dem PostBack Pattern, bei dem alle Formularinhalte per POST-Request an das aktuelle Formular zurueckgeschickt werden. Jede gerenderte HTML-Seite die im Browser zu sehen ist, stellt eine View da und hat einen eindeutigen Identyfier, den ViewState. Der ViewState Identyfier muss bei jedem POST-Request mitgeschickt werden, da ansonsten der Komponentenbaum nicht reproduziert werden kann. In so einem Fall wuerde nach der ersten Phase des JSF-Lifecycles gleich die sechste Phase ausgefuehrt und eine leere Seite gerendert werden.
Mit einem RegularExpressionExtractor in jMeter ist es moeglich die ViewState auszulesen und beim naechsten Request als Post-Parameter mitzuschicken. Dazu benoetigt es ein rechtsklick auf die Thread Group in einem jMeter-Testfall, wo schliesslich im Contextmenue folgendes ausgewaehlt werden muss “Add” – “Post Processors” – “Regular Expresseion Extractor”.

Das Formular zum Extractor muss dann wie folgt ausgefuellt werden:

Reference Name: jsfSTATE
Regular Expression: <input type="hidden" Name="org\.apache\.myfaces\.trinidad\.faces\.STATE" value="(.+?)">
Template: $1$
Match No. (0 for Random): 0
Default Value:

Dannach muss bei jedem Post-Request der Parameter “org.apache.myfaces.trinidad.faces.STATE” auf den Wert “${jsfSTATE}” gesetzt werden. Die Parameter zu einem Request koennte demach so aussehen:

loginName: name
loginPassword: password
org.apache.myfaces.trinidad.faces.FORM: loginForm
org.apache.myfaces.trinidad.faces.STATE: ${jsfSTATE}
source: loginButton

Um Testergebnisse ansehen zu können muss noch ein “Summary Report” hinzugefügt werden.

Der Testplan ist jetzt soweit fertig gestellt. Jetzt muss nur noch ein Test aufgezeichnet werden. Dafür fügen wir einen “HTTP Porxy Server” der Work Bench hinzu.

Der Proxy Server muss jetzt auf einen bestimmten Port und auf eine bestimmte URL konfiguriert werden, auf die er lauschen soll. Ganz wichtig ist auch der unterste Bereich der Maske, “URL Patterns to Exclude”. Hier sollten unbedingt mit regulären Ausdrücken Bilder, CSS und JavaScript ausgeschlossen werden, da diese für den Test unwichtig sind.

Nach dem starten des Proxy Servers muss dieser noch im Browser eingestellt werden. Im Firefox ruft man dazu den Menüpunkt “Preferences -> Advanced -> Network” auf und klickt dann auf “Settings”.

Hier muss jetzt der entsprechende Proxy mit dem richtigen Port eingetragen werden. Ganz wichtig ist hierbei das, dass Feld “No Proxy for” leer ist.

Wenn der Proxy eingetragen ist, kann damit begonnen werden die WebAnwendung aufzurufen. Jedes Klick und jedes Seitenaufruf auf den Anwendung wird nun von jMeter aufgezeichnet. Ein einfaches Test könnte z.B. darin bestehen sich an einer WebAnwendung anzumelden und alle Links im Hauptmenü durchzuklicken. Anschliessend könnte man sich abmelden.

Nach dem der Test aufgezeichnet ist, kann der Proxy Server in jMeter gestoppt werden.

Wenn alles geklappt hat, dann sieht der linke Bereich in jMeter wie folgt aus:

Jetzt ist es wichtig das bei jedem Request die Request-Variable “org.apache.myfaces.trinidad.faces.STATE” den Wert “${jsfSTATE}” hat. Die Variable kommt aus dem “Regular Expresseion Extractor”.

Dieser Wert muss leider bei jedem Request per Hand gesetzt werden. Einen anderen Weg habe ich bisher noch nicht gefunden. Wenn das erledigt ist, kann ein einfacher Test gestartet werden, über den Menüpunkt “Run -> Start”.

Nach dem Ausführen des aufgezeichneten Tests ist im Summary Report die Ergebnissliste zu sehen:

Jetzt kann man in der Thread Group die “Number of Threads (users)” auch hoch schrauben auf 50 und sich anschauen wie die Anwendung reagiert.

Ich hoffe die Anleitung war hilfreich und hat weiter geholfen.

Eine Beschreibung zu jMeter + MyFaces Core ist hier im Wiki zu finde:

http://wiki.apache.org/myfaces/PerformanceTestingWithJMeter?highlight=%28jmeter%29

SQLException: Can’t call commit when autocommit=true

In einem Projekt bei einem grossen Energieversorger habe ich Hibernate 3.X zusammen mit Spring 2.5 konfiguriert, nach der Beschreibung von Eberhard Wolf. Dier Persistenzschicht hat wunderbar funktioniert, bis ich einen Stresstest mit jMeter gemacht habe. Als ich einen aufgezeichneten Testfall in zehn Threads gestartet habe, trat bei einigen Threads folgender Fehler auf:

hibernate java.sql.SQLException: Can't call commit when autocommit=true

Daraufhin habe ich in der Hibernatekonfiguration den Wert explizit auf false gesetzt:

hibernate.connection.autocommit=false

leider blieb der erhoffte Erfolg aus. Die Loesung habe ich in einem JIRA-Eintrag gefunden. An die connection.url muss der Wert “relaxAutoCommit=true” angehaengt werden. Also z.B.

hibernate.connection.url=jdbc:mysql://localhost:3306/project?relaxAutoCommit=true

Seit dem ich meine Connection.url abgeaendert habe ist der Fehler nicht wieder augetreten.

Factory already available for this class loader

In einem JSF-Projekt habe ich einen SessionExpired-Filter eingebaut. Der Filter implementiert das javax.servlet.Filter Interface und leitet den Benutzer auf die Login-Seite um, wenn die Session abgelaufen ist. Der Filter hat an sich super funktioniert, bis ich wieder einen Stresstest mit jMeter gemacht habe. Dabei ist im Filter folgende Exception geworfen worden:

java.lang.IllegalStateException: Factory already available for this class loader.

Ich habe den Fehler zuerst in meinem Filter gesucht, der zweite Uebeltaeter den ich in Verdacht zog war Tomcat. Doch tatsachlich war es wieder einmal die JSF Komponenten Libary ADF/Trinidad.

http://www.mail-archive.com/adffaces-issues@incubator.apache.org/msg02333.html

Wenn nach einem Serverstart zwei Threads gleichzeitig auf die Applikation zugreifen kommt der Dispatcher durcheinander.
Ganz grosses Kino!!!

Tomcat 6 Cluster

Die folgende Beschreibung bezieht sich auf Tomcat 6.0.14 mit Java 5.
Eeine Anleitung zum Aufbauen eines Tomcat-Clusters mit Session-Replikation ist in der offiziellen Tomca-Dokumentation zu finden: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Ich beschreibe hier die Probleme auf die gestoßen bin beim Aufbau eines solchen Clusters.

Bei einem Cluster werden die HttpSessions auf alle Nodes (Teilnehmer/Server) im Cluster repliziert (kopiert). Somit ist es egal auf welche Node der Loadbalancer vor dem Cluster weiterleitet, da alle Sessions auf allen Nodes zur Verfuegung stehen. Das hat den Vorteil der hohen Verfuegbarkeit aber den Nachteil eines hohen Speicherverbrauchs.

Wenn sich ein Kunde auf eine Webapplikation einloggt die auf so einem Cluster laeuft, dann kriegt er nichts davon wenn der Server auf dem er gerade arbeitet abstuerzt. Der Loadbalancer leitet den naechsten Request vom Kunden auf einen anderen Server im Cluster um, wo er mit seiner alten Session weiter arbeiten kann. Bei einem einfachen Loadbalancing ohne Cluster und ohne Session-Replikation muesste sich der Kunde wieder neue anmelden an der WebApplikation und seine HttpSession waere fuer immer verloren.

Nach jedem Request wird geprueft ob sich eine Aenderung in der HttpSession ergeben hat. Wenn dies der Fall ist, wird das Delta auf alle anderen Nodes im Cluster repliziert. In der offiziellen Doku ist das folgende Stueck Konfigurationscode zu finden, das in die <TOMCAT_HOME>/conf/server.xml eingefuegt werden muss, um Tomcat im Cluster laufen zu lassen.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8"  >

 <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"  />

 <Channel className="org.apache.catalina.tribes.group.GroupChannel"  >
   <Membership className="org.apache.catalina.tribes.membership.McastService"
               address="228.0.0.4"
               port="45564"
               frequency="500"
               dropTime="3000"  />
   <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
             address="auto"
             port="4000"
             autoBind="100"
             selectorTimeout="5000"
             maxThreads="6"  />

   <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"  >
       <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"  />
   </Sender>
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"  />
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"  />
 </Channel>

 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""  />
 <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"  />

 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
           tempDir="/tmp/war-temp/"
           deployDir="/tmp/war-deploy/"
           watchDir="/tmp/war-listen/"
           watchEnabled="false"  />

 <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"  />
 <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"  />
</Cluster>

Nach dem Starten des Tomcats habe ich dann folgende Fehlermeldung bekommen:

SEVERE: Unable to process request in NioReceiverjava.net.SocketException: Invalid argument

Das Problem kann behoben werden indem man dem Transport einen timeout und einen KeepAliveCount zuweist.

<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" timeout="60000" keepAliveCount="120000"  />

Mein Eintrag in der server.xml sieht so aus.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"  >

 <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"  />

 <Channel className="org.apache.catalina.tribes.group.GroupChannel"  >
   <Membership className="org.apache.catalina.tribes.membership.McastService"
               address="228.0.0.4"
               port="45564"
               frequency="500"
               dropTime="3000"  />
   <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
             address="auto"
             port="4002"
             autoBind="100"
             selectorTimeout="5000"
             maxThreads="12"  />

   <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"  >
     <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" timeout="60000" keepAliveCount="120000"  />
   </Sender>
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"  />
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"  />
 </Channel>

 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""  />
 <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"  />

 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/"
           deployDir="/tmp/war-deploy/"
           watchDir="/tmp/war-listen/"
           watchEnabled="false"  />

 <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"  />
 <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"  />
</Cluster>

Wenn die Nodes alle auf der gleichen Hardware laufen dann muessen die Ports vom Receiver angepasst werden. Die server.xml des zweiten Tomcats auf der gleichen Hardware sieht bei mir so aus:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"  >

 <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"  />

 <Channel className="org.apache.catalina.tribes.group.GroupChannel"  >
   <Membership className="org.apache.catalina.tribes.membership.McastService"
               address="228.0.0.4"
               port="45564"
               frequency="500"
               dropTime="3000"  />
   <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
             address="auto"
             port="4001"
             autoBind="100"
             selectorTimeout="5000"
             maxThreads="12"  />

 <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter"  >
   <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
              timeout="60000"
              keepAliveCount="120000"  />
 </Sender>
 <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"  />
 <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"  />
</Channel>

 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""  />
 <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"  />

 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
           tempDir="/tmp/war-temp/"
           deployDir="/tmp/war-deploy/"
           watchDir="/tmp/war-listen/"
           watchEnabled="true"  />

 <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"  />
 <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"  />
</Cluster>

Der naechste Fehler auf dem ich gestossen bin ist:

java.net.SocketException: Invalid argument

Wenn der Tomcat mit der Option -Djava.net.preferIPv4Stack=true aufgerufen wird, dann tritt der Fehler nicht auf. Unter Linux kann mit folgendem Befehl die Umgebungsvariable “JAVA_OPTS” erweitert werden.

export JAVA_OPTS=$JAVA_OPTS;-Djava.net.preferIPv4Stack=true

bei starten des Tomcats werden alle Optionen aus der JAVA_OPTS gelesen.
Nun lief das Cluster endlich erfolgreich, also habe ich angefangen einige Applikation drauf zu deployen. Damit eine Applikation Clusterfaehig ist muessen alle Objekte die in der HttpSession abgelegt werden Serialisierbar sein. Ausserdem muss der Deploymentdescriptor (web.xml) folgenden Eintrag enthalten.

<distributable/>

Das deployen selber wollte ich ueber den Farmdeployer erledigen. Dabei soll die WAR-File nach “/tmp/war-listen” kopiert werden und der Farmdeployer verteil die Applikation auf alle Nodes im Cluster. Das hat leider nicht funktioniert! Nach einigem forschen im Internet bin ich in der tomcat-mailinglist auf einen Eintrag gestossen, aus dem ich erfahren habe das der farmdeployer noch nicht wirklich funktioniert und die Entwickler noch dran sind.

Also habe ich meine Applikationen per Hand deployt. Bei einer IceFaces Applikation konnte die Session mit folgender Fehlermeldung nicht repliziert werden:

java.io.NotSerializableException: com.icesoft.faces.webapp.http.servlet.ServletExternalContext

Bei einer Struts 2 + Spring 2.5 Anwendung ist die Replikation an folgender Fehlermeldung gescheitert.

java.io.NotSerializableException: org.springframework.jdbc.datasource.DriverManagerDataSource

Alles nicht so wirklich zufriedendstellend. Da gibt man sich muehe alle Seine Objekte Serialisierbar zu halten und kriegt man vom Framework nicht Serailisierbare Objekte in den Weg gelegt. Das bedarf einer intensiven Nachforschung.

Loadbalancing mit Apache2 + Tomcat 6 + mod_proxy

In dem Blogeintrag Loadbalancing mit Apache2 + Tomcat 6 + mod_jk 1.2.X habe ich beschrieben wie ein Loadbalancing mit dem “mod_jk” Module eingerichtet werden kann. Dieser Blogeintrag verfolgt das gleich Ziel, jedoch nicht mit dem “mod_jk” sondern mit dem “mod_proxy” Modul.

Im gegensatz zum “mod_jk” Modul muss das “mod_proxy” Modul nicht von einer externen Quelle heruntergeladen werden, es ist beim apache2 Webserver dabei. Unter Debian muss gegebenenfalls noch folgendes Kommando angesetzt werden.

apt-get install apache-modules

Ein Loadbalancing macht nur Sinn, wenn mindestens zwei Tomcats die gleiche Applikation ausliefern. Der Blogeintrag N Tomcats auf einer Maschine beschreibt wie zwei Tomcats zu konfigurieren sind damit sie parallel auf der selben Maschine laufen.

Gehen wir davon aus das wir eine Webapplikation namens “geo” haben die auf den zwei Tomcats “tomcat1” und “tomcat2” laufen. die “server.xml” von tomcat1 hat folgenden Eintrag:

<Engine name="Catalina"    defaultHost="localhost"    jvmRoute="tomcat1"   >

und die von tomcat2 dementsprechend:

 <Engine name="Catalina"    defaultHost="localhost"    jvmRoute="tomcat2"   >
 

Ganz wichtig hierbei ist das Attribut “jvmRoute”, in dem der Name des jeweiligen Tomcats gesetzt ist. Auf diesen Namen wird aus dem apache2 Webserver heraus referenziert.

In der Konfigurationsdatei des apache2, meisstens “/etc/apache2/httpd.conf” oder “/etc/apache2/apache.conf”, muss das “mod_proxy” Modul geladen werden. Das kann so aussehen:

LoadModule proxy_module libexec/apache2/mod_proxy.so
LoadModule proxy_connect_module libexec/apache2/mod_proxy_connect.so
LoadModule proxy_ftp_module libexec/apache2/mod_proxy_ftp.so
LoadModule proxy_http_module libexec/apache2/mod_proxy_http.so
LoadModule proxy_ajp_module libexec/apache2/mod_proxy_ajp.so
LoadModule proxy_balancer_module libexec/apache2/mod_proxy_balancer.so

Hier wird ein wenig mehr geladen als nur das reine “mod_proxy” Modul. Die Pfade muessen natuerlich an das entsprechende Betriebssystem angepasst sein.

Nach dem erfolgreichen laden des Moduls kann der Loadbalancer konfiguriert werden.

ProxyPass /geo balancer://apacheBalance stickysession=JSESSIONID

<Proxy balancer://apacheBalance>
 BalancerMember ajp://localhost:8009/geo route=tomcat1 loadfactor=50
 BalancerMember ajp://localhost:8010/geo route=tomcat2 loadfactor=50
 </Proxy>

In der ersten Zeile wird der Webserver angewiesen alle Anfragen mit der URI “geo” an den balancer mit dem Namen “apacheBalance” zu delegieren, der im Abschnitt weiter unten definiert ist. Der Balancer kann beliebig viele “BalancerMember” haben und unterstuetzt nicht nur das ajp Protokoll sondern auch http. Das Attribut “route” im BalancerMember referenziert auf den “jvmRoute” des Tomcats, die wir weiter oben eingestellt haben.

Der “loadfactor” muss ein Wert zwischen 0 und 100 sein und legt die Lastverteilung fest. Wenn beide balancer einen Wert von 50 haben, dann wird die Last gleich verteilt. Wuerde der “tomcat1” einen loadfactor von 10 haben und der andere einen loadfactor von 90, dann wuerde “tomcat2” neunmal mehr Last bekommen als “tomcat1”.
Die Applikation ist nun ueber die URL “http://localhost/geo&#8221; erreichbar.

Bei der ersten Anfrage leitet der apache2 auf eines der BalancerMember weiter, z.B. tomcat2. Alle weiteren Anfragen von dem gleichen Client werden ebenfalls an den tomcat2 weitergeleitet, sofern eine HttpSession benutzt wird. Um sich zu merken welche Clients zu welchen Tomcat weitegeleitet werden sollen, legt apache2 eine Cookie beim Cleint an. Dieser Cookie besteht aus der SessionId und dem Namen des jeweiligen Tomcats.

Bei allen weiteren Anfragen wird dieser Cookie mitgeschickt und so weis der apache2 immer genau an welchen Tomcat er die Anfrage weiterleiten soll. Dieses Verhalten macht natuerlich nur Sinn wenn die Webapplikation Kundendaten in einer HttpSession vorhaelt. Wenn das nicht der Fall ist, ist es vollkommen egal an welches der beiden Tomcats die nachfolgenden Anfragen weitergeleitet werden.
Und genau hier liegt der Vorteil vom “mod_proxy” Modul gegenueber dem “mod_jk” Modul. Mod_proxy haengt im Cookie nur dann den Namen des Tomcats an die SessionId wenn die HttpSession nicht leer ist.

Ein weiterer Vorteil des Moduls ist der balancer-manager, eine kleine Webanwendung die den aktuellen Status des Balancers zeigt. Um die Applikation einzubinden muss folgender Eintrag in die apache2 Konfigurationsdatei hinzugefuegt werden.

<Location /balancer-manager>
          SetHandler balancer-manager
</Location>

Nach der Aenderung muss der apache2 natuerlich neu gestartet werden und dannach ist die Anwendung uber die URL “http://localhost/balancer-manager&#8221; erreichbar.

Ueber den Balancer-Manager kann auch zur Laufzeit der loadfactor veraendert werden. Soll einer der beiden Tomcats (tomcat2) aus bestimmten Gruenden vom Netz genommen werden, sollte dieser einen loadfactor von 1 zugewiesen bekommen und der andere einen loadfactor von 99. Damit ist sichergestellt das alle weietern Requests an den Tomcat mit dem loadfactor 99 weitergeleitet werden. Nach einer gewissen Zeit sind auf dem tomcat2 keine HttpSessions mehr offen und er kann problemlos vom Netz genommen werden.

Um den unbefugten Zugriff auf den balancer-manager zu verhindern sollte er durch ein Passwort geschuetzt werden.

<Location /balancer-manager>
          SetHandler balancer-manager

          AuthType Basic
          AuthName "balancer manager "
          AuthUserFile /etc/apache2/htpassbalancer
          Require valid-user
</Location>

Die Passwortdatei kann mit folgendem Kommando angelegt werdne.

htpasswd -c /etc/apache2/htpassbalancer username

Multiple MessageBundles in JSF ManagedBeans

In einer bestehenden Web-Applikation, mit MyFaces 1.1.5 wollte ich aus einer MessageBean auf verschiedene MessageBundles zugreifen. Die betroffene Klasse erbt von der BaseBean, welche folgende Methode zur Verfügung stellt:

public String getStringFromResourceBundle(final String key) {
    return ResourceBundle.getBundle(getApplication().getMessageBundle()).getString(key);
}

Die faces-config habe ich um zwei weitere ResourceBundles erweitert.

<application>
 <default-render-kit-id>org.apache.myfaces.trinidad.core</default-render-kit-id>
 <variable-resolver>
     org.springframework.web.jsf.DelegatingVariableResolver
 </variable-resolver>
 <locale-config>
     <default-locale>de</default-locale>
 </locale-config>
 <message-bundle>
     de.itservices.onlineservices.resources.gui.status
 </message-bundle>
 <message-bundle>
     de.itservices.onlineservices.resources.gui.buildno
 </message-bundle>
 <message-bundle>
     de.itservices.onlineservices.resources.gui.messages
 </message-bundle>
</application>

In der betroffenen Klasse habe ich über die Methode aus der BaseBean eine Property aufgerufen dien in der status.properties hinterlegt ist. Der Aufruf endete in einer MissingResourceException.

java.util.MissingResourceException: Can't find resource for bundle java.util.PropertyResourceBundle, key Revision

Wenn mehrere message-bundles in der faces-config eingetragen sind, wird in der Implementierung von MyFaces 1.1.5 der letzte Eintrage genommen. Properties aus den ersten beiden message-bundles stehen nicht zur Verfügung.
Soll in einer ManagedBean auf mehr als auf eine message-bundle/Properties zugegriffen werden, muss der Zugriff erst implementiert werden. Hier eine mögliche Lösung.

URL url = this.getClass().getClassLoader().getResource("de/firma/projekt/resources/buildno.properties");
String path = url.getPath().replaceAll("%20", " ");
Properties prop = new Properties();
prop.load(new FileInputStream(path));
String zeit = prop.getProperty("Time");

Die zweite Zeile ist ein Workaround für Pfade mit Leerzeichen auf Windows-Systemen, aber das ist ein anderes Thema.
Ich habe mir die JSF 1.2 Spezifikation heruntergeladen und dannach durchsucht. Die Spez. ist zu diesem Thema nicht transparent, sie sagt nichts darüber aus, was geschehen soll wenn mehrere message-bundles in der faces-config.xml eingetragen sind und aus einer ManagedBean versucht wird darauf zuzugreifen. Es waere natuerlich schoen wenn die Methode getApplication().getMessageBundle() einen MessageBundle zurueckgeben wuerde der die Properties aus allen MessageBundles enthaelt die in der faces-config.xml eingetragen sind.

Einrichten eines Postfix Mailserver

Auf Debian-Servern ist standardmaessig Exim als Mailserver vorinstalliert. Der ist nicht schlecht aber mein Lieblingsmailserver ist nun mal Postfix. Exim kann wie folgt vom System entfernt werden.

apt-get remove exim*

Nun ist der Weg frei fuer Postfix.

apt-get install postfix

Und zu einem guten MTA gehoert auch ein guter MUA.

apt-get install mutt

Der Mailserver ist nun installiert und muss nur noch konfiguriert werden. Die Hauptkonfigurationsdatei fuer Postfix ist die “/etc/postfix/main.cf” Die Standardeinstellungen in der Datei sind meisstens sehr sinnvoll, so das nur wenige Variablen angepasst werden muessen.
Als erstes sollte der Hostname und die Domain angepasst werden. In meinem Fall sieht das so aus:

myhostname = ploin.de
mydomain = ploin.de

Die Variable “mydestination” legt fest fuer welche Domain der Server E-Mails entgegen nehmen soll. Es mach Sinn hier den eigenen Server einzutragen.

mydestination = ploin.de, localhost, 192.344.559.2

Die Variable “mynetworks” legt fest welche Adressen vertrauenswuerdig sind. Hier sollte auch mindestens der eigene Server drin stehen.

mynetworks = 127.0.0.0/8

die Variable “alias_maps” enthaelt den Pfad zu einer Datei, in der alle E-Mailadressen enthalten sind.

alias_maps = hash:/etc/aliases

Eine “/etc/aliases” koennte so aussehen:

reiz: pumukel
mueller: mueller@gmx.de

In der ersten Zeile wird Postfix angewiesen alle E-Mails mit der Empfaengeradresse reiz@ploin.de an den Benutzer pumukel des Systemes zuzuweisen. Die E-Mails landen also im Postfach vom pumukel Account.
In der zweiten Zeile wird der Mailserver angewiesen alle E-Mail mit der Empfaengeradresse mueller@ploin.de an die E-Mailadresse mueller@gmx.de weiterzuleiten.
Wenn die Datei geaendert wird, muss nicht gleich der Mailserver durchgestartet werden um die anederungen zu uebernehmen. Ein einfaches “postalias” mit der Datei als Parameter reicht aus.

postalias /etc/aliases

Nach dem Befehl sind die Aenderungen gueltig.
Der E-Mailserver sollte jetzt eingerichtet und betriebsbereit sein. Er nimmt E-Mails entgegen und speichert sie in den ensprechenden Postfaechern der Benutzer die in der /etc/aliases eingetragen sind.

Kompilieren mit Ant

Beim kompilieren mit dem Build-Tool Ant werden oft drei Tasks definiert, preCompile, executeCompiler und postCompile. In dem Task preCompile werden alle Arbeiten erledigt die vor dem Kompiliervorgang statt finden muessen, wie z.B. das Erstellen eines Zielverzeichnisses.

<property name="projectBuild"   value="${projectHome}/build/classes"   />

<fileset id="classesFiles"   dir="${projectBuild}"   />

<target name="preCompile"  >
   <mkdir dir="${projectBuild}"   />
</target>

Im Task executeCompiler findet das eigentliche Kompilieren statt.

<property name="compileTarget"   value="1.5"   />

<path id="compilerSourceFiles"  >
    <pathelement path="${projectSources}"   />
</path>

<path id="compilerLibraryFiles"  >
    <fileset dir="${libraries}"  >
       <include name="**/*.jar"   />
    </fileset>
    <fileset dir="${j2eeLibraries}"  >
       <include name="**/*.jar"   />
    </fileset>
</path>

<target name="executeCompiler"   depends="preCompile"  >
   <javac destdir="${projectBuild}"   target="${compileTarget}"  >
      <src refid="compilerSourceFiles"   />
      <classpath refid="compilerLibraryFiles"   />
   </javac>
</target>

Im Task postCompile sind alle Arbeiten beschrieben die nach dem kompilieren ausgefuehrt werden sollen, wie z.B. das kopieren aller nicht Quellcode-Dateien vom Source-Verzeichnis in das Build-Verzeichnis.

<target name="postCompile"   depends="executeCompiler"  >
    <copy todir="${projectBuild}"  >
        <fileset dir="${projectSources}"  >
            <exclude name="**/*.java"   />
        </fileset>
    </copy>
</target>

Der Tag “exclude” teilt Ant mit das er rekursiv durch alle Verzeichnisse gehen soll und dabei alle Dateien die mit “.java” enden auslassen soll.

Ant + Tomcat (hotdeploy)

Unter einem hotdeployment versteht man das deployen einer Applikation ohne dabei den Applikationserver/Servletcontainer herunterzufahren. Um mit Ant ein hotdeployment aus einem Tomcat durchfuehren zu koennen, muss vorher Der TCD (Tomcat Client Deployer) heruntergeladen werden, der hier zur Verfuegung steht: http://tomcat.apache.org/download-60.cgi. Die JAR-Files aus dem TCD sollten im Classpath zu finden sein.
Die Nachfolgenden Properties sollten fuer ein hotdeployment deklariert werden:

<property name="path"   value="/myapp"  />
<property name="url"   value="http://localhost:8080/manager"  />
<property name="username"   value="tomcat"  />
<property name="password"   value="tompassword"  />

Mit dem folgenden Eintrag wird der Ant Task fuer den Manager konfiguriert.

 <path id="deployer.classpath"  >
<fileset dir="${basedir}/lib"  >
<include name="*.jar"  />
</fileset>
</path>

<taskdef resource="org/apache/catalina/ant/catalina.tasks"
classpathref="deployer.classpath"  />
 

Mit den folgend Targets kann eine Applikation neu geladen, undeployt und deployt werden.

 <target name="reload"   >
<reload url="${url}"  username="${username}"  password="${password}"  path="${path}"  />
</target>

<target name="undeploy"   >
<undeploy url="${url}"  username="${username}"  password="${password}"  path="${path}"  />
</target>

<target name="hotdeploy"   >
<deploy url="${url}"  username="${username}"  password="${password}"  path="${path}"  war="${projectWARFile}"   />
</target>

Eine ausführliche Beschreibung aller Task ist auf der Homepage von Tomcat zu finden.

http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html

Nicht selten endet das hotdeployment in einem OutOfMemmoryException. Mit dem Mechanismus des HotDeployments hatte Tomcat schon immer Probleme. Ich empfehle fuer das deployen auf Tomcats nur harddeployments, die ich im vorherigen Blogeintrag beschrieben habe.

Ant + Tomcat (harddeploy)

Der folgende Eintrag zeigt wie Ant aus einer WebApplikation eine *.war Datei backt und diese auf dem Tomcat deployt. Gehen wir davon aus das vorhergehende Task eine WebApplikation aus einem Svn-Server ausgecheckt und erofolgreich kompiliert haben. Der folgende Task baut eine *.war Datei.

<target name="buildWARFile"  >
 <war destfile="${projectWARFile}"  >
   <fileset refid="webContentFiles"   />
   <lib refid="libFiles"   />
   <classes refid="classesFiles"   />
   <webinf refid="webinfFiles"   />
 </war>
</target>

Die Attribute “refid” verweisen alle auf “filesets” (siehe Ant-docu). Die eben generiert Datei wird mit dem nachfolgenden Task deployt.

<target name="deploy"   >
 <exec executable="net"   >
   <arg line='stop "  Apache Tomcat 5.5.20 Server 3"  ' />
 </exec>
 <delete dir="${appHome}"   />
 <mkdir dir="${appHome}"   />
 <unwar src="${projectWARFile}"   dest="${appHome}"   />
 <exec executable="net"   >
   <arg line='start "  Apache Tomcat 5.5.20 Server 3"  ' />
 </exec>
</target>

Die erste Anweisung ruft das Kommandozeileninterface “net” auf mit den Uebergabeparametern ‘stop “Apache Tomcat 5.5.20 Server 3″‘. Das Kommandozeileninterface “net” steuert auf Windows Servern die Systemdienste. Damit das ganze funktioniert muss Tomcat als Windows Systemdienst installiert sein.
Sobald der Apache Tomcat heruntergefahren ist, werden mit den nachfolgenden Zeilen das Verzeichnis der Zielapplikation geloescht, ein neues Verzeichnis angelegt, die *.war Datei wird in das neu erstellte Verzeichnis entpackt und zum Schluss wird der Apache Tomcat als Systemdienst gestartet.
Der Vorgang kann ein bis zwei Minuten dauern, dannach sollte die Applikation zur Verfuegung stehen.

Auf einem Debian Linux System sieht der Task ähnlich aus.

<target name="deploy"   >
 <exec executable="/opt/tomcat/bin/shutdown.sh"   />
 <delete dir="${appHome}"   />
 <mkdir dir="${appHome}"   />
 <unwar src="${projectWARFile}"   dest="${appHome}"   />
 <exec executable="/opt/tomcat/bin/startup.sh"   />
</target>