everflux

Bei der Umstellung von Jetty 6 zu Jetty 7 gab es (wie bereits geschildert) das eine oder andere an Überraschungsmomenten. So auch bei einem länger laufenden Request ( Fileupload anschließendes Parsen und Datenbank Updates die sich einige Minuten hinziehen können).

Die saubere Lösung wäre hier natürlich dem Nutzer eine Art Fortschritts-Anzeige zu präsentieren. Da die Funktion jedoch so bereits getestet ist, und auch kein Umbau geplant war, sollte es so bleiben. Lediglich Jetty hat hier (mal wieder) einen Strich durch die Rechnung gemacht: Geschlossene Verbindungen die mit org.eclipse.jetty.io.EofException und vielen hässlichen Stacktraces kommentiert wurden. Erst hatte ich die Applikation in Verdacht.

Dann den Browser – macht der Browser vielleicht die Verbindung zu, wird der Socket nur solange wie „keep-alive“ erlaubt ist offen gehalten? Mit etwas wireshark / tcpdump konnte ich dann beweisen: Es war Jetty. Der Server schloss die Verbindung bevor der Prozess fertig war.

Zum Glück kann man aber den idle Timeout von Jetty konfigurieren, das ist die Zeit, in der eine Verbindung ohne Fortschritt fortbestehen darf. (Fortschritt wäre hier ein gesendetes oder empfangenes Byte.) Hier kann man noch gut in die Falle tappen, dass die Zeit in Milisekunden angegeben werden muss – lediglich der verdeckte Hinweis, dass der Wert „grob gesagt“ in den Parameter für Socket.setSoTimeout(int) übersetzt wird, bringt einen hier auf die Spur.

Für das Jetty Maven Plugin sieht das dann so aus:

<configuration>
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>8080</port>
<maxIdleTime>600000</maxIdleTime> <!-- 10 minutes in milliseconds! -->
<lowResourcesMaxIdleTime>600000</lowResourcesMaxIdleTime>
</connector>
</connectors>
</configuration>


Es hat nur wenige Monate gedauert, aber dann konnte ich endlich einen besonders nervigen Fehler finden. Ich verwende Maven (wie fast immer) als Buildsystem und habe ein Projekt, dass Eclipse BIRT verwendet.
BIRT nutzt die Eclipse OSGi Plattform und daher werden beim Start einige Bilbiotheken benötigt. Nun gab es das Problem, dass dies im Tomcat nach einer kleinen Anpassung des Classpath prima funktionierte – nicht jedoch wenn ich das Maven Jetty Plugin verwendet habe. Trotz lt. Dokumentation korrekter Konfiguration über webAppConfig und extraClasspath Elemente.

Die Lösung war dann schließlich nicht mehr das maven-jetty-plugin in Version 6.1.2 sondern das – Achtung – jetty-maven-plugin in Version 7.2.1.v20101111 (die Versionnummer ist kein Witz) zu verwenden. Offenbar ein Jetty Bug – anders kann ich es mir nicht erklären.

Und so sieht dann die vollständige Konfiguration aus, die bei mir dann endlich auch zum Testen schnell und komfortabel funktioniert:

<plugin>
  <groupId>org.mortbay.jetty</groupId>
  <artifactId>jetty-maven-plugin</artifactId>
  <version>7.2.1.v20101111</version>
  <configuration>
    <webAppConfig>
      <extraClasspath>${BIRT_HOME}/lib/engineapi.jar;${BIRT_HOME}/lib/coreapi.jar; \
${BIRT_HOME}/lib/modelapi.jar;${BIRT_HOME}/lib/org.apache.commons.codec_1.3.0.v20100518-1140.jar; \
${BIRT_HOME}/lib/scriptapi.jar</extraClasspath>
    </webAppConfig>
  </configuration>
</plugin>

Entwickelt man mit Jetty als Servlet Container, so fällt der im Vergleich zu Glassfish relativ hohe Aufwand für Re-Deployments auf: Startet man Jetty per „mvn jetty:run“ für jedes Deployment erneut, so dauert der Neustart erst mal relativ lange, dazu geht noch die gerade aktive Session verloren. So muss man sich gegebenenfalls nach jeder Änderung bzw. jedem Restart erneut anmelden.
Das kann man relativ einfach ändern: Jetty verfügt über die Möglichkeit die Session zu persistieren – dazu müssen natürlich Session Objekte serialisierbar sein, aber das sollten diese ja sowieso sein. (Stichwort „Session migration“ und „Clustering“)
Leider findet sich auf der Jetty Homepage lediglich eine Anleitung für Jetty 6 – Jetty 7 wird nun von Eclipse weiter entwickelt und damit gehen einige Änderungen einher, für die ich hier eine Beispielkonfiguration habe:

<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.2.1.v20101111</version>
<configuration>
  <webAppConfig>
    <sessionHandler implementation="org.eclipse.jetty.server.session.SessionHandler">
      <sessionManager implementation="org.eclipse.jetty.server.session.HashSessionManager">
      <storeDirectory>${basedir}/target/sessions/</storeDirectory>
    </sessionManager>
  </sessionHandler>
<contextPath>/${project.artifactId}</contextPath>
</webAppConfig>
<!--
<reload>automatic</reload>
<scanIntervalSeconds>2</scanIntervalSeconds>
<scanTargets>
<scanTarget>target/classes/</scanTarget>
</scanTargets>-->
</configuration>
</plugin>

Mit dieser Einstellung werden die Session Daten in dem Order „target/sessions“ persistiert, und man kann bei einem Neustart dort weitermachen, wo man aufgehört hat.

Nicht immer genuegt es, wenn man ein Servlets auf andere Pfade oder Patterns mappt, manchmal möchte man bereits auf den Context Root ein Servlet mappen. Der übliche Work-Around sieht so aus, dass man bspw. in einer „index.jsp“ einen redirect auf eine tatsächlich einem Servlet zugeordnete URL (über den Pfad oder Datei Extension) macht, das könnte so aussehen:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:redirect url="/myServlet"/>

Das ist aber nicht immer praktikabel – nun soll es darum gehen ein Servlet direkt auf den „/“ Pfad zu mappen – dafür gibt es mehrere Möglichkeiten:

1. Das Default Servlet ersetzen, dazu wird auf den Root Pfad „/“ in der web.xml ein Mapping angelegt:
<servlet-mapping>
<servlet-name>myServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
2. Ab Servlet Spezifikation kann auch ein Servlet in der welcome-file-list in der web.xml gemappt werden:
   <welcome-file-list>
<welcome-file>myServlet</welcome-file>
<welcome-file>index.html</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Im folgenden beschreibe ich die Vor- und Nachteile der verschiedenen Ansätze, und welche Erfahrungen ich mit verschiedenen Web Containern dabei gemacht habe. Weiterlesen »

Verwendet man Maven für ein Java JSP Projekt und Netbeans als IDE, so koennen erstaunliche Fehler entstehen: Um mit Servlets zu arbeiten, wird man im Maven die Abhängigkeit auf die Servlet API deklarieren. Da der Webcontainer sich später um die Implementierung der Servlets – und auch das Kompilieren von JSP Seiten – kümmert, gibt man als Scope „provided“ an.

Beispielsweise so:

<dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
   <scope>provided</scope>
</dependency>

Damit funktioniert die Entwicklung dann auch prinzipiell – bis auf rote Hinweise und Fehlermeldungen im Netbeans JSP Editor:

„package javax.servlet.jsp does not exist“
(cannot find symbol)

und so weiter und so fort. Bei allen JSP Direktiven, JSP Deklarationen etc. gibt es einen Hinweis darauf, dass Netbeans da etwas im Classpath fehlt. Und Netbeans hat dabei auch Recht – wenn man die JSP API nicht ebenfalls als Projekt Abhängigkeit deklariert. Hier hilft also ein kleiner Zusatz in der Maven pom.xml, der so aussehen könnte:

<dependency>
   <groupId>javax.servlet.jsp</groupId>
   <artifactId>jsp-api</artifactId>
   <version>2.1</version>
   <scope>provided</scope>
</dependency>

Hier ist die JSP Version 2.1 passend zur Servlet API 2.5 gewählt. Anschließend einmal „clean and build“ in Netbeans geklickt, und die „package javax.servlet.jsp does not exist“ Fehler sind behoben.

Eine in die Jahre gekommene Java Webanwendung, die mit dem Spring Framework (Web mvc) umgesetzt wurde, sollte ein wenig modernisiert werden. Vor allem die Umstellung auf Spring 3 und auf Annotationen basierende Controller war einiges an Migrationsarbeit.

Während des Testens viel mir auf, dass bei jedem Redeployment im Tomcat und im Glassfish 3 der Speicher knapper wurde.  Nichts sonderlich ungewöhnliches bei Java Webanwendungen. Der beste Kandidat für ein sogenanntes Permgen-Leak ist dabei der MySQL Connector (Datenbank Treiber fuer MySQL), wenn dieser mit der Webanwendung im WAR Archiv liegt, und nicht vom Container bereitgestellt wird. Durch die Art, wie sich JDBC Treiber bei Java „anmelden“ können dann Speicherlecks entstehen, wenn die Webanwendung deaktiviert bzw. redeployt wird.

Das besonders nervige an Speicherlecks, die sich auf die Permanent Generation (Permgen) auswirken, ist dass eine einzige Referenz auf den Classloader reicht, um zu verhindern dass der Garbage Collector aufräumt. Das bedeutet, dass man den Erfolg seiner Maßnahmen erst dann sieht, wenn man alle Lecks abgedichtet hat: Eine echte Geduldsprobe. Weiterlesen »

Ubuntu eignet sich hervorragend als Entwicklungsumgebung für Java Anwendungen. Sei es auf dem Desktop oder auf dem Server, bei Ubuntu bekommt man ein aktuelles Sun JDK oder OpenJDK, einen planbaren Releasezyklus. Auch ist ein Unix-artiges Betriebssystem in meinen Augen zum Arbeiten angenehmer als z.B. Windows.

Hat man auf einem entfernten Server, der aber per Netzwerk (oder VPN) erreichbar ist, einen Java Applikationsserver, wie z.B. Glassfish, laufen, so bietet sich JMX zum Monitoring und Management an. Besonders die „VisualVM“ Anwendung macht die Arbeit dabei sehr leicht und übersichtlich. Der Start erfolgt einfach per „jvisualvm“, anschließend können lokale Anwendungen sofort analysiert werden, für entfernte Rechner ist eine JMX Verbindung erforderlich.

Für VisualVM gibt es auch ein Plugin für Glassfish, dies kann über „Tools -> Plugins“ installiert werden. Danach fügt man den entfernten Host hinzu, hier kann man den Hostnamen oder eine IP Adresse eintragen: Weiterlesen »

Eine weitere Erfahrung mit Glassfish gemacht – und was dazu gelernt. Zumindest bei der Servlet 2.4 Spezifikation ist die Reihenfolge der inneren Tags im web.xml Deployment Descriptor relevant. Während Tomcat zufrieden dahin schnurrt, wenn man dies nicht beachtet, gibt es Fehler beim Deployment im Glassfish:

com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while deploying the app : java.io.IOException: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'servlet-name'. One of '{"http://java.sun.com/xml/ns/j2ee":filter-name}' is expected.

oder

com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while deploying the app : java.io.IOException: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'url-pattern'. One of '{"http://java.sun.com/xml/ns/j2ee":servlet-name}' is expected.

Dabei ist das kein Fehler vom Glassfish: Er hält sich streng an die Spezifikation und validiert die web.xml beim Parsen mit SAX (Streaming Parser) gegen die DTD.

Also einfach darauf achten: Erst kommt der Servlet/Filter Name und dann die Zuordnung auf ein URL-Pattern bzw. bei Filtern auch auf einen Servlet Namen, wie im folgenden Beispiel:

<servlet-mapping>
<servlet-name>admin</servlet-name>
<url-pattern>/admin/*</url-pattern>
</servlet-mapping>

<filter-mapping>
<filter-name>cacheFilter</filter-name>
<servlet-name>print</servlet-name>
</filter-mapping>

Ab Servlet Spec 2.5 darf man übrigens auch mehrere Mappings auf einmal angeben – falls man noch mit der web.xml und nicht mit Annotationen arbeitet spart es Tipparbeit und ist übersichtlicher.

Ich wollte eigentlich nur etwas ganz simples: Continuous Deployment. Das ist der neueste Trend nach Continous Integration habe ich mir sagen lassen. Und gerade wenn man in einem Team arbeitet ist es schon vorteilhaft, wenn man einen stabilen Build staendig deployt hat.

Hudson ist mein bevorzugter Buildserver (auch wenn Bamboo wirklich ansprechender ist, aber eben auch eine Ecke teurer und nicht OpenSource) – und es gibt auch ein Plugin fuer Hudson, mit dem man ein Deployment anstarten kann: http://wiki.hudson-ci.org/display/HUDSON/Deploy+Plugin
Leider funktioniert das bei dem Glassfish nicht, wenn Hudson nicht auf dem selben Server läuft, wie der Glassfish. (Das sollte/dürfte der Regelfall sein.)
Weiterlesen »

Updates haben nicht immer nur gutes – manchmal gibt es auch neue Fehler oder Animositäten. So auch bei Maven:
Seit dem Maven Ressource Plugin Version 2.4.x wurden einige Ressource Dateien nicht mehr korrekt gefiltert. Das Filtern von Ressourcen kann man z.B. dazu verwenden, um automatisch Build oder Versionsnummern einzufügen.

Die Konfiguration dafür ist einfach:

<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
</includes>
</resource>
</resources>

Schon kann man z.B. in der version.properties dann revision = ${buildNumber} eintragen, und erhält nach jedem Build die inkrementierte Build-Nummer. (Vom Maven Buildnumber Plugin)

Nur funktionierte es plötzlich nicht mehr. Genauer gesagt, es funktionierte nicht mehr bei allen Dateien. Die Ursache (nach langem Suchen): Das Zeichen „@“ ist als neuer Delimiter hinzugefügt worden. Enthielt jetzt eine der zu filternden Dateien ein „@“ eben als solches, und nicht als Teil eines Patterns, wurde das Filtern abgebrochen. Eine Fehlermeldung oder Warnung habe ich nicht gesehen – mag aber sein, dass Maven die irgendwo mal ausgespruckt hat.

Abhilfe schafft hier die folgende explizite Konfiguration des Maven Resource Plugin:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.4.3</version>
<configuration>
<useDefaultDelimiters>false</useDefaultDelimiters>
<delimiters>
<delimiter>${*}</delimiter>
</delimiters>
</configuration>
</plugin>

Damit wird das das alte Verhalten des Plugins wieder hergestellt, und „@“ Zeichen als Trennzeichen für Ersetzungen ignoriert.

Vielleicht gibt es auch mal einen offiziellen Code fix – Maven Bug: http://jira.codehaus.org/browse/MRESOURCES-117