everflux

Es fing damit an, dass Twitter mich ausgeloggt hat. Und ich mich nicht wieder einloggen konnte. Die native App faselte was von ‚retry later‘ oder falschem Passwort, die Webseite erzählte etwas von einem bekannten technischen Problem. Jedoch war auf status.twitter.com nichts zu sehen. Da ich davor einige Experimente mit Spring Integration und Twitter gemacht hatte und dabei auch mehrfach rate-limit Fehlermeldungen erzeugt hatte (versehentlich, wirklich!), machte ich mir Sorgen dass ich jetzt Twitter kaputt gemacht haben könnte.

Oder zumindest Twitter ernsthaft auf mich sauer sein könnte. Hilft alles nichts, muss man mal tiefer einsteigen.

Schaut man sich die Fehlermeldung an, sieht es aus, als wenn die OAuth Tokens, die Twitter zur Authentifizierung einsetzt und auch selbst ausstellt, von Twitter nicht verifiziert werden können. Die Signatur sei falsch. NSA Gedanken! Da ist bestimmt ein Schlapphut Schuld!

…. oder etwas ganz banales? Die Uhrzeit des Servers sieht komisch aus. Exakt ein Jahr in der Zukunft.

So ganz habe ich zwar keine Idee wie so was mit der Hardware Uhr passieren könnte – aber ich habe eine Hypothese, was ein Programmierer tun könnte um den Fehler auszulösen.

Der Fehler trat ab ca. 0 Uhr UTC am 29.12. auf – zumindest hab ich ihn da bemerkt.

Es ist Montag der 29. 12. im Jahr 2014. Morgen ist Dienstag, 30., auch 2014. Mittwoch ist Silver, 31. – noch 2014. Das sind drei Tage. Die nächsten Tage sind alle schon in 2015.

Wenn sich jemand bei einem Date-Format einen super schwer zu findenden Bug einbauen möchte, dann verwendet er „YYYY“ statt „yyyy“ für die Jahreszahl. Das ist nämlich dann das „Week-Year“ und nicht das kalendarische Datum. Das ist dann das Jahr zu dem die Kalenderwoche gehört. Und es ist bereits KW 1 von 2015….

Das klingt abwegig? Habe ich schon zig mal in Code-Reviews gesehen. Die Wahrscheinlichkeit dass man dafür Sensibilität entwickelt hat, ohne dass man davon mal gebissen wurde halte ich für recht gering.

Inzwischen hat Twitter dazu ein Statement veröffentlicht

Between 4:00 and 9:25 PST today some users were unable to sign in to twitter.
This issue was due to a bug in our front end code, which has been patched.
We apologize for any inconvenience caused by this.

Da scheine ich gar nicht schlecht gelegen zu haben mit dem Bug – es war zumindest nicht die Hardware-Uhr und 04:00 PST ist 00:00 UTC 🙂

Zu solchen Verwirrungen traegt es u.U. bei, dass in Ruby „Y“ genau das richtige ist und in Java „y“ – aber „Y“ auch erstmal funktioniert und keine augenscheinlichen Probleme verursacht.

Referenzen:

• http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
• http://apidock.com/ruby/DateTime/strftime

Inzwischen sind multi-core oder sogar multi-CPU Maschinen weit verbreitet. Um etwas besser abschätzen zu können, wie gut eine Anwendung mit steigender Anzahl von CPU (Kernen) skaliert, möchte man manchmal eine Anwendung auf einzelne Kerne oder sogar einen einzigen beschränken.
Auch fuer den Fall, dass man den selben Rechner als Test-Agent und zur Ausführung des Tests (also client und server) verwenden möchte, kann es sich lohnen die zu testende Anwendung und den Test-Agenten mit beschränkten Ressourcen zu starten, damit diese nicht so stark miteinander konkurrieren.
Unter Linux (Ubuntu, Debian, Arch…) gibt es das Utility „taskset“. Damit kann die CPU Affinität eines Prozesses beim start oder sogar nachträglich eingestellt werden.
Beispielsweise kann man damit dann eine Java Webanwendung folgendermaßen auf einen Core begrenzen:

taskset 1 [start-kommando]


In meinem Fall nutze ich jmeter um gegen eine so gestartete Anwendung zu testen:

env MAVEN_OPTS="$MAVEN_OPTS -noverify" taskset 1 mvn -Dspring.profiles.active=dev jetty:run


Schon beim Start bemerkt man recht deutlich, wie gut Java von Mehrprozessorarchitekturen profitiert. Selbst wenn die eigene Anwendung nicht stark parallelisert ist.

Ubuntu ist für mich die präferierte Entwicklungsplattform, sicherlich geht es vielen anderen (Java) Softwareentwicklern ähnlich. Und im Sinne von OpenSource möchte man OpenJDK auch auf dem eigenen Rechner übersetzen können. Das ist z.B. nützlich, wenn man selber das Java mal patchen oder debuggen möchte, aber auch um z.B. die neuesten Entwicklungen von Java 8 auf dem eigenen System ausprobieren zu können.

Im Vergleich zu früher macht der Übergang von Ubuntu zu MultiArch auf 64 bit Systemen etwas Probleme, jedoch ist das mit einem „gewusst wie“ schnell erledigt. Als Vorbedingung muss ein Java (OpenJDK 6/7, Oracle JDK) installiert sein. Ich habe in meinem Fall unter /usr/lib/jvm/jdk1.7.0 ein Oracle JDK installiert.

Als nächstes benötigt man Mercurial, die hgforest extension und ein paar Bibliotheken für den Build. Ich installiere hgforest im Home-Verzeichnis, wer das nicht mag, muss die Pfade entsprechend anpassen:

apt-get install mercurial
apt-get install gawk g++ libcups2-dev libasound2-dev libfreetype6-dev libx11-dev libxt-dev libxext-dev libxrender-dev libxtst-dev libfontconfig1-dev
hg clone https://bitbucket.org/pmezard/hgforest-crew/overview/ "$HOME/hgforest"

Die hgforest Erweiterung fuer Mercurial traegt man direkt in der Mercurial Konfiguration ein, indem man die Datei ~/.hgrc editiert und folgenden Abschnitt ergaenzt (auch hier gilt dann ggf. den Pfad anzupassen)

Test driven development ist inzwischen schon fast ein alter Hut. Um so mehr ist es wichtig, dass die Produktivität stimmt. Hält man sich an bestimmte Namenskonventionen, so unterstützen alle modernen IDEs schnelles Umschalten zwischen Test-Code und Produktionscode.

Dazu nennt man seine Testklasse genauso wie die Class-under-test, beispielsweise „FibonacciTest“ falls die eigentliche Klasse „Fibonacci“ heißt. Mittels Control-Shift-T kann man in Netbeans dann zwischen den beiden Klassen umschalten. Heute habe ich noch was gelernt: Control-F6 startet den Unit test – und zwar auch dann, wenn man ihn nicht fokussiert hat, also in der eigentlichen Klasse im Editor ist. („Fibonacci“ in diesem Beispiel)

Das spart unnötige Kontext-Switche, macht einfach Spaß und bringt Produktivität. Mein Tipp: Ausprobieren!

Mit Alt-F6 startet man übrigens alle Tests zu einem Projekt. (Falls einem nicht komische Ubuntu Tastenkürzel dazwischenfunken.)

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem „Master Password“ gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter „0“. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die „echte“ Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern „lediglich“ eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Lange gesucht, doch gefunden:

ERROR: Aborted Maven execution for InterruptedIOException
java.net.SocketTimeoutException: Accept timed out


Jenkins (bzw. Hudson) bricht dann mit dieser Fehlermeldung den Build Prozess ab:

java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
	at java.net.ServerSocket.implAccept(ServerSocket.java:462)
	at java.net.ServerSocket.accept(ServerSocket.java:430)
	at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:167)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:221)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:668)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1374)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Finished: ABORTED

Beheben über advanced und dort in die MAVEN_OPTS hinzufügen:

-Djava.net.preferIPv4Stack=true

Anschließend sollte der Build wieder korrekt funktionieren. Alternativ kann man dies auch als globale Environment Variable setzen, das Problem wird mehrere Java Anwendungen betreffen und nicht nur den CI Server.

Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:

openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:

serial=4FCD4C50631D3BB4C747A319E816AD5D
subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de
issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
serial=254B8A853842CCE358F8C5DDAE226EA4
subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Nun müssen alle Zertifikate untersucht werden:

openssl x509 -text -in cert-0.pem

Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:

tkruse@charix:~$ openssl x509 -text -in cert-2.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Ein „betagtes“ altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.

Ich habe ein merkwuerdiges SSL Problem mit Java 7 (Build 147, dem Release Candidate) im Zusammenhang mit Online-Banking und Jameica/Hibiskus:

Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
 at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:873)
 at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:804)
 at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
 ... 19 more

Schaut man sich dazu den Source Code an, sieht man schnell, dass leider die verursachende Exception verschluckt wird. (Das kommt davon, wenn Committer und Reviewer identisch sind…)
Meine Idee war also, OpenJDK selber zu bauen und da ggf. besseres Logging einzubauen. Die im Internet veröffentlichten Anleitungen sind alle ein paar Jahre alt und nicht mehr ganz korrekt, daher hier meine Ergebnisse zum Nachmachen.
Ich habe Ubuntu als System verwendet, dort ist eine Übersetzung von OpenJDK / Java 7 sehr einfach.
OpenJDK wird mittels Mercurial verwaltet, zur Hierarchiebildung wird die Mercurial Forest extension benötigt (und Mercurial). Ist das „mercurial“ Paket bereits installiert so kann man die Forest extension einfach herunterladen:

hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

Diese muss nun in die .hgrc eingetragen werden: (das „….“ durch den Pfad zum Download ersetzen)

[extensions]
forest=......hgforest/forest.py
fetch=

Danach installiert man die Build Abhängigkeiten:

sudo apt-get install build-essential gawk libasound2-dev libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev libxrender-dev

Und checkt per mercurial-forest die Sourcen fuer OpenJDK aus:

hg fclone http://hg.openjdk.java.net/jdk7/jdk7 jdk7

Da beim späteren Build noch Java Abhängigkeiten heruntergeladen werden müssen, hab ich noch folgendens in die Ant Konfiguration eingesetzt: ~/.antrc

ANT_OPTS=”$ANT_OPTS -Dallow.downloads=true”

Für den build benötigt man ein existierendes Java, und setzt folgenden Umgebungsvariablen:

export ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
unset JAVA_HOME
export LANG="C"
make sanity

Da sollten keine Fehler zu sehen sein und gibt dann den „make“ Befehl (dauert bei mir rund 40 Minuten):

make

Und kann es dann aus dem aktuellen Verzeichnis testen ob „java“ vorhanden ist:

build/linux-amd64/bin/java -version

Bei mir sieht das dann folgendermassen aus:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Fertig.
(Ja man benötigt wirklich keine „binary plugs“ o.a“. mehr!)

Update: Für Ubuntu 12.04 benötigt man folgende Pakete:

libcups2-dev, libfreetype6-dev, liboss4-salsa-dev

Und muss (Stand Mai 2012) auch wegen der neueren Kernelversion als die bei OpenJDK bekannten eine Environment Variable setzen:
export DISABLE_HOTSPOT_OS_VERSION_CHECK=ok

JUnit 4 bringt die (bessere) Syntax von assertThat über Hamcrest Matcher mit. Und nicht nur die Syntax ist besser, es gibt für viele Testfälle bereits „Matcher“, die das Leben erleichtern können.
Genauso kann einem das Leben aber auch erschwert werden: JUnit bringt eben nur ein Subset der Hamcrest Funktionalität mit. Den Rest kann man über die entsprechenden Hamcrest Bibliotheken hinzufügen. Und genau da gilt es nun aufzupassen: JUnit bringt eben bestimmte Versionen der Bilbiotheken mit – und dann kann es zu Konflikten kommen, die sich zur Test-Laufzeit erst zeigen:

org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
at org.hamcrest.text.IsEmptyString.(IsEmptyString.java:18)

Die Lösung ist dann JUnit ohne eigene Versionen von Hamcrest etc. zu verwenden (die „no-dependencies“ Version), und entsprechend die Abhängigkeiten selber aufzulösen.

Mit Maven sieht dann der Einsatz von JUnit, Mockito und Hamcrest z.B. folgendermaßen aus:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit-dep</artifactId>
  <version>4.8.2</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>1.8.5</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-core</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-library</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>

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>