everflux

Wie bereits in meinem anderen Eintrag zu Glassfish 3.1 beschrieben, ist seit der Implementierung der Servlet 3.0 Spezifikation in Glassfish 3.1 der Session Cookie standardmäßig auf „httpOnly“ gesetzt – dies kann Probleme mit einigen JavaScript Frameworks verursachen.

In dem web.xml Deploymentdescriptor kann dies umkonfiguriert werden, im glassfish-web.xml Descriptor ist dafür leider keine Möglichkeit vorgesehen. Weblogic, auch von Oracle mit BEA zugekauft, verhält sich dabei genauso, auch hier ist der Session Cookie auf httpOnly gesetzt – kann jedoch über den Weblogic spezifischen Deployment Descriptor unabhängig von der web.xml umkonfiguriert werden.

Und Glassfish 3.1 unterstützt nun auch ein Subset des Weblogic Deployment Descriptors um Weblogic kompatibel zu sein. (Vermutlich ist dies auch ein Grund, aus dem die Cookies httpOnly sind, um mit Weblogic konform zu sein.) Auch wenn es komisch ist, dass Glassfish selber keine Möglichkeit vorsieht das Verhalten im eigenen Deployment Deskriptor zu konfigurieren – über den Umweg des Weblogic spezifischen Descriptors geht es dann:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<session-descriptor>
<cookie-http-only>false</cookie-http-only>
</session-descriptor>
</weblogic-web-app>


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.

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 »

Wie man hier lesen kann, ist am 6. November der neue Glassfish v3 Application Server veröffentlicht worden.

Glassfish ist ein modularer Application Server, der inzwischen nicht nur die Java Plattform unterstützt. (PHP, (J)Ruby on Rails, Grails, … sind ebenfalls verfügbar.) Was macht Glassfish zu etwas besonderem?
Als Referenzimplementierung werden erste Features von JEE 6 (Java Enterprise Edition) in dem Glassfish v3 zu sehen sein. Ebenfalls mit an Bord ist OSGi Support, Comet, RESTful web Services. Dank Metro ist die Interoperabilität mit .net sichergestellt, Tooling für Netbeans und Eclipse steht dem Entwickler ebenfalls zur Seite.

Fazit: Glassfish hat das Potential durch die schlanke aber auch modular erweiterbare Struktur ein attraktive Plattform für verschiedenste Applikationen zu werden.

Einen guter Überblick über Glassfish und die neuen Glassfish Features findet man auch in den Sun Screencasts. (Wer noch garnicht mit Glassfish gearbeitet hat, findet einen guten Einstieg in diesem Screencast: Introducing Glassfish v3)

Netbeans 6.5 Milestone build 1 ist verfügbar (www.netbeans.org). Die Liste der neuen Features und Updates macht wirklich neugierig!

Unter anderem hat Netbeans verbesserten JavaScript Support (incl. JavaScript Debugger), Groovy und Grails werden von Haus aus unterstützt, und auch PHP ist jetzt direkt mit von der Partie. Weiterlesen »