everflux

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 »

Nachdem für Ubuntu Intrepid der Support ausgelaufen ist, blieb nichts anderes übrig: Ein Upgrade auf Lucid ist nötig, um weiterhin Sicherheitsupdates für Ubuntu zu bekommen. (Und wann hat man dazu schon so gut Zeit, wie zu Weihnachten…)

Nach einigen Zwischenstationen über u.a. Jaunty und Karmic samt Kernel Oops wegen ACPI und APIC Problemen auf dem alten Nvidia Board war dann endlich Lucid auf der Platte. Allerdings ohne AVM Fritz Treiber – AVM hat den Support eingestellt und es gibt (natürlich) keine OpenSource Treiber. Glücklicherweise gibts im Ubuntuusers-Wiki eine wunderbar funktionierende Anleitung. Für Ubuntu Lucid habe ich folgende Schritte durchgeführt (die Build Abhängigkeiten waren noch von Intrepid vorhanden)

wget https://belug.de/~lutz/pub/fcpci/fritz-fcpci-src-2.6.31_untested.tar.bz2
tar -jxf fritz-fcpci-src-2.6.31_untested.tar.bz2
cd fritz-fcpci-src-2.6.31_untested
make clean
make all
mkdir /lib/modules/`uname -r`/extra
cp fcpci.ko /lib/modules/`uname -r`/extra/

Die letzten beiden Schritte werden wohl nach jedem Kernel Update faellig. In der /etc/modules steht das fcpci Modul noch drin, so dass es beim Systemstart automatisch geladen wird.
Danke an Lutz Willek dem wir das gepatchte Paket zu verdanken haben.

Für Asterisk und Capi sollte das Ubuntu Paket asterisk-chan-capi den entsprechenden Channel fuer Asterisk bereitstellen. Leider ist in Lucid 10.04.1 das Paket defekt, es wurde mit anderen Compileroptionen übersetzt als Asterisk und kann daher nicht geladen werden.
Ein einfacher workaround sieht so aus:
apt-get install asterisk-dev
apt-get source asterisk-chan-capi
cd asterisk-chan-capi-1.1.4
dpkg-buildpackge -b
cd ..
dpkg -i asterisk-chan-capi_1.1.4-1_i386.deb

Das Asterisk Capi Channel Modul sollte in /etc/asterisk/modules.conf unterhalb von res_features eingetragen werden, z.B. so:

load => res_features.so
load => chan_capi.so

Danach muss Asterisk noch neu gestartet werden.

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 »

Immer wieder werde ich gefragt: Wie geht ein Youtube Download? Der Hintergrund: Nicht immer kann man Videos in Echtzeit abrufen, manchmal ist aufgrund einer längeren Reise oder anderen Gründen keine Internet Versorgung vorhanden. Youtube Videos zu speichern, wenn man sowas absehen kann, lohnt also. (Was rechtliche Aspekte angeht, bin ich jedoch überfragt, ich gehe davon aus, dass es in Deutschland legal ist – wir zahlen ja dafür Urheberrechtsabgaben auf alle Speichermedien  und PCs –  aber sicherlich in mindestens einem Land der Welt verboten ist.) Weiterlesen »

Wikileaks tritt derzeit ein wenig in den Schatten von Julian Assange. Der Person, die sich als „Blitzableiter“ bezeichnet, und eine der wenigen Personen ist, die Wikileaks ein Gesicht geben.

Auf Youtube findet sich eine recht interessante Dokumentation ueber Wikileaks: http://www.youtube.com/watch?v=PvmfOaZ34Pk (die letzten Minuten sind hier http://www.youtube.com/watch?v=WDJqb3jXeN8) 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