everflux

Oracle hat heute den Glassfish 3.1 freigegeben – gleichzeitig als Open Source und als Oracle Glassfish Edition. Es gibt eine Menge neues, und dazu gehören auch neue Probleme.

Ich verwende Glassfish schon seit geraumer Zeit um mittels „Continuous Deployment“ für aktuell entwickelte Anwendungen eine separate Umgebung zu haben, in der ich und Kollegen testen können. Das ganze funktioniert mittels eine CI-Servers (Hudson Jenkins in diesem Fall), Maven und einem Deploy Plugin.

Auch mit Glassfish 3.1 funktionierte das Deployment prima – also hier war kein Update von Jenkins oder dem Deploy Plugin erforderlich. Auch die Anwendung startete – jedoch funktionierte nichts. Exceptions über ungültige Sessions gab es, auch Log-Einträge vom hier für Ajax eingesetzten DWR (Direct Web Remoting)

2011-02-28 18:57:13,037 [http-thread-pool-8090(2)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.
2011-02-28 19:03:02,105 [http-thread-pool-8090(5)] ERROR o.d.dwrp.Batch - A request has been denied as a potential CSRF attack.

Dank Firebug etwas schlauem Rumraten und Probieren fand ich dann heraus: Glassfish 3.1 setzt Session Cookies per Default auf „HTTP Only“. Dazu gibt es bereits ein Ticket im Glassfish Tracker: GLASSFISH-15730

Es gibt nun mehrere Möglichkeiten für die nötige Kompatibilität mit Bestandsanwendungen zu sorgen:

Wird man die Anwendung zukünftig immer in einem Servlet 3.0 kompatiblen Container deployen, so kann man in der web.xml das Verhalten umkonfigurieren:

<web-app>
  <session-config>
    <cookie-config>
      <http-only>true</http-only>
    </cookie-config>
  </session-config>
</web-app>

Alternativ kann man bei DWR den CSRF Check deaktivieren, wovon ich jedoch abraten würde:

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
  <init-param>
    <param-name>crossDomainSessionSecurity</param-name>
    <param-value>false</param-value>
  </init-param>
</servlet>

Die letzte Möglichkeit ist – in diesem Fall – auf DWR 3 umzustellen, hier wurde das Problem grundsätzlich gelöst, so dass nicht mehr per JavaScript auf den Session Cookie zugegriffen werden muss. (Siehe DWR-26) Leider gibt es von DWR 3 bisher noch kein Release, sondern lediglich vorab-Versionen.

Das Problem tritt übrigens auch mit Tomcat 7 auf, und nicht nur mit Glassfish 3.1 – ich frage mich, ob dies Verhalten am Ende sogar in der Servlet 3 Spezifikation vorgegeben ist.
Natürlich betrifft dies nicht ausschließlich DWR, sondern auch andere Anwendungen, die per JavaScript auf den Session Cookie zugreifen wollen/müssen.

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 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.

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

Firefox ist an sich ein recht ordentlicher Browser. Die Zeiten in denen er in Punkto Geschwindigkeit und „Schlankheit“ ganz vorne war, sind allerdings vorbei. Aber damit koennen viele gut Leben – Firefox ist recht stabil, die Geschwindigkeit ist auch nicht schlecht und vor allem die Flexibilitaet dank der beinahe unendlichen Fuelle an Erweiterungen (Extensions / Add-Ons) machen den Firefox Browser attraktiv.

Dabei spielt es keine Rolle, ob es um Entwickler geht, die Firebug mit den dafür ebenfalls verfügbaren diversen Erweiterungen nutzen, oder den Gelegenheitssurfer der dank Adblock-Plus schneller und weniger genervt das Internet konsumieren kann. Für andere Nischen und spezielle Bedürfnisse gibt es ebenso viele Plugins von „Spass“ bis „Produktivität“ ist alles vertreten.

Jedoch wuchs der Neid bei mir wenn ich auf Chrome / Chromium blickte – ich wollte Firefox auch etwas schneller haben. Bekannt für Nachteile bei der Performance sind eben gerade jene Erweiterungen, die einem das Leben so schön erleichtern. Also habe ich einige deaktiviert, es wurde in der tat etwas schneller. Damit war das erledigt. Erfolg!

Bis mir auffiel, dass irgendetwas nicht stimmte. Bei Downloads verschlang Firefox immense Mengen an Speicher – ein Vielfaches dessen, was die Datei selber haben würde. Und auch die CPU Belastung, vor allem bei Downloads, wuchs dramatisch.

Erst hatte ich das Flashplugin in Verdacht – in der Regel trifft man damit den Richtigen, genauso wie pauschal auf Windows schimpfen. Aber daran lag es nicht, ich hatte extra keine Flash Seiten aufgemacht.

Erst als ich alle von Firebug abhaengigen Erweiterungen (und nicht nur Firebug selber) deaktiviert hatte, sowie TamperData und LiveHttpHeaders war endlich alles wie es sein sollte. Firefox brauchte weder Unmengen an Memory noch ging die CPU Last bei Downloads in die Höhe. Welches Plugin tatsächlich verantwortlich war, habe ich nicht mehr untersucht. Vermutlich ist es nicht gut, wenn man Plugins, die Firebug benötigen, aktiviert lässt, aber Firebug selber deaktiviert.

Um mir Arbeit zu sparen (wer moechte schon immer alle Erweiterungen ein- und ausschalten) habe ich mir mittels eine zweiten Firefox Profils das Leben leichter gemacht: Es gibt jetzt ein „dev“ Profil für Entwicklung, da ist dann alles aktiviert, dass sich der Web-Entwickler wünscht. Daneben sind auch deutlich weniger, bzw. andere Bookmarks gesetzt: „Führe mich nicht in Versuchung“.

Um den Entwicklungs-Firefox zu starten, habe ich mir eine zusaetzliche Verknuepfung (mit Werkzeug-Symbol) in der Ubuntu Linux Taskbar angelegt, diese ruft folgendes Kommando auf:
firefox -no-remote -P dev

Mittels „-P“ kann man das Profil auswählen, welches verwendet werden soll, das „-no-remote“ verhindert, dass bei einer bereits gestarteten Firefox Instanz (z.B. des default Profils) lediglich ein neues Fenster aufgemacht wird.

Probiert es mal aus – Kommentare und Feedback erwünscht!

Manchmal kann man bestimmte Assoziationen einfach nicht verhindern. Als Computer-Kind bedeutet die 1337 etwas besonderes (siehe auch Leetspeak) und so schmunzelte ich doch sehr als die Webanalyse Software Piwik mir folgende Backlink Statistik präsentierte:

Piwik ist übrigens eine interessante Alternative zu Google Analytics, es handelt sich um eine kostenlose OpenSource Software, die mittels JavaScript, PHP und MySQL Webseitenstatistiken erzeugt. Bei großen Projekten wird die Last auf der Datenbank allerdings deutlich spürbar – vielleicht ist eine relationale Datenbank für Webanalyse eben nicht so gut, wie BigTable (Google) oder andere NoSQL Systeme. Im Gegensatz zu Google Analytics liefert Piwik jedoch auch eine Backlink, Pagerank und Alexa Analyse direkt dazu.

Bei der Migration einer MySQL Datenbank gab es ein merkwürdiges Phänomen: Nach dem Import der Daten von einem Server auf einen Ubuntu Lucid Server wurden die Daten falsch angezeigt. Es sah aus, als wenn sie base64 codiert wären, oder ein esoterisches Encoding Problem zugeschlagen hätte.

Die Vermutung lag nahe, dass entweder der Dump (mittels mysqldump erzeugt) defekt war, oder falsch importiert wurde. (Der Import wurde über den mysql Kommandozeilen Client gemacht, MySQL lag auf beiden Systemen in der Ubuntu Lucid Version 5.1.41 vor.). Das Thema MySQL, Encoding, Collation und Charset kann sich dabei als sehr verwirrend herausstellen. Weiterlesen »

Das habe ich bisher noch nie gesehen. Die gesamte Webseite an Google geopfert! Aber von vorne: SpringSource, der Hersteller des Spring Framework, bietet auf seiner Webseite Downloads und andere interaktive Elemente an.
Auf der Webseite kommt Google Analytics zum Einsatz, und natürlich auch JavaScript. Das frappierende: Ist JavaScript deaktiviert, oder Google Analytics geblockt, funktioniert die Webseite nicht mehr richtig. In der Tat hat damit SpringSource, die Firma die stets „loose coupling“ und „keine Abhängigkeiten“ als Verkaufsargumente nutzte eine Abhängigkeit zu Google eingeführt.

Weiterlesen »