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.

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>


So einfach kann Datenrettung sein: Meine Mutter hat auf einer Digitalkamera Bilder gehabt, die ihr sehr am Herzen liegen. Leider wurden die Fotos von der Digicam irgendwie gelöscht – und der Frust sehr groß.

Ich hab mir die Speicherkarte der Kamera geschnappt, diese mit einem USB Kartenleser an einen Ubuntu Rechner gehängt, und mittels „dd“ ein Abbild der Karte gemacht:

dd if=/dev/sdc of=~/Desktop/rettung.img bs=8192

Das ganze dauerte eine Weile, da es sich um eine 32 Gigabyte Speicherkarte handelte. Nun konnte ich gefahrlos auf dem Abbild arbeiten – soweit mir bekannt löschen Kameras die Fotos nicht sofort, sondern geben, wie bei Dateisystem im Computer, den Speicher lediglich zur Wiederverwendung frei. Somit sah ich gute Chancen auf einer erfolgreiche Datenrettung mit Bordmitteln.

Nachdem das Abbild erstellt war, habe ich mit dem Programm „photorec“ das Abbild durchsuchen lassen (ggf. das Paket testdisk installieren, wenn photorec noch nicht verhanden ist):

photorec rettung.img

Nach einer geraumen Weile fanden sich dann die geretteten Bilder in dem von mir angegebenen Ordner. Ich liebe es, wenn ein Plan funktioniert.

Bei Ubuntu wurde der Bereich zum „Anfassen“ der Fensterrahmen auf sagenhafte einen Pixel verkleinert – möchte man ein Fenster nun breiter ziehen muss man schon gut zielen.

Komfortabler geht das derzeit lediglich, wenn man über eine Maus mit drei Tasten verfügt (oder die mittlere Taste simuliert): Hält man die „Alt“ Taste fest, kann man mit der mittleren Maustaste quasi beliebig ins Fenster klicken, und die Größe anpassen. Das ist am Anfang etwas ungewohnt, geht jedoch sogar noch schneller als erst den Fensterrahmen anzusteuern – selbst wenn dieser etwas breiter ist (oder wieder wird).

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>

Au weia, da hat sich o2 ja wieder nen echten FAIL geliefert: Ich hatte Anrufe von der Rufnummer +4935188815303 (also Deutschland 0351 88815303), aber immer nach 1x Klingeln, schneller als ich ans Handy gehen konnte, war der Anruf weg.

Dann hab ich mal zurückgerufen: Es ist eine O2 Nummer. Ich lande im O2 Callcenter – immerhin ist die 035188815303 ja per Festnetz Flatrate kostenlos erreichbar. Nach schier unendlichen „jetzt gleich aber wirklich tuuuut tuuuut leider doch alle im Gespräch bitte bleiben sie drann“ geht ein Callcenter Agent ran. Ich möchte wissen, was O2 von mir möchte und warum man mir keine Chance gibt, ranzugehen. „Das ist ein Systemfehler, das System wählt zu kurz an“. ACHSO! (Predictive Dailer anyone?)

Dann gebe ich meine Daten und und die gute Frau erklärt „o2 und Alice arbeiten jetzt zusammen und… “ – „nein danke bloß nicht. Hab ich auch schon 2x gesagt, dass ich bereits DSL habe. Schönen Tag noch.“

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.

Schon seit einem guten Jahr nutze ich das US Tastaturlayout unter Ubuntu als Standardlayout. Gerade zum Entwickeln konnte ich wegen der besseren Position von Semikolon und geschweiften Klammern schnell einen Produktivitätsgewinn feststellen.

Doch dann kamen auch die Rückschläge: Euro Zeichen, Paragraphenzeichen (§) und Umlaute sind nicht mehr verfügbar. Für Umlaute behelfen sich einige mit Unicode Eingabe, oder Copy-Paste-Vorlagen. Ich habe mir bisher damit geholfen, dass ich die Rechtschreibkorrektur einfach „ue“ in „ü“ habe umwandeln lassen. Hilft jedoch nicht z.B. beim „§“-Zeichen.

Und da habe ich jetzt das Feature „Compose Key“ gefunden. Damit kann man – fast wie bei LaTeX – Buchstaben zusammensetzen. Dazu aktiviert man erstmal die Einstellung ein „Compose Key“ auf der Tastatur zu haben, ich habe dazu die rechte Alt-Taste verwendet. (System->Preferences->Keyboard, Layout auswählen, „Options“)

Anschließend kann man mittels <compose>-<u>, und <„> ein „ü“ zusammensetzen. Das Paragraphenzeichen geht z.B. über <compose>-<s>, <o>

Das sind Dinge, da versteh ich nicht, wie es dazu kommen kann. Wirklich nicht. Es geht um die Verbesserung des Notfalldienstes für gesetzlich (und privat) versicherte Patienten in Deutschland. Bisher ist es an mir vorbei gegangen, aber spätestens mit dieser Presseerklärung der Kassenärztlichen Vereinigung Westfalen Lippe (KVWL) ist wohl auch NRW dran: Statt bisher zum Ortstarif muss man eine 0180-5 Servicenummer anrufen, wenn man außerhalb der regulären Sprechstundenzeiten einen medizinischen Notfall hat. Der Vorteil: Die Rufnummer ist einheitlich, nicht mehr vom jeweiligen Ortsnetz abhängig.

Das war nicht immer so! Zumindest in Münster gab es verschiedene Rufnummern für die verschiedenen Bereiche, nämlich die „192 92“. Die Vorwahl konnte man wählen oder es sein lassen. Was war da jetzt uneinheitlich? Eine kurze Google Suche erweckt auch den Anschein, als sei die „19292“ relativ einheitlich verfügbar, lediglich bei manchen Gemeinden ist eine andere Rufnummer für die Fachrichtung zu wählen. Aber auch das ist nichts unmögliches – und wenn doch, wählt man eh besser die „112“. Weiterlesen »