Content from 2013-01

Java Webstart und WELD

posted on

Für meinen Arbeitgeber habe ich ein Programm entwickelt, das wir nutzen Zeiten zu erfassen und in unser Projektmanagement einzukoppeln. Um in der Firma einfach auf allen Rechnern immer die neuste Softwareversion zur Verfügung zu haben, habe ich mich dafür entschieden Java Webstart einzusetzen. Diese Technik hatte ich auch bereits für einige andere Java-Anwendungen von meinen Kunden eingesetzt.

Neu dieses mal war nun allerdings, dass ich nicht Spring sondern CDI für die Dependency Injection gewählt habe. CDI implementiert durch WELD ist bei uns auf der Arbeit hierzu meist der Standard der Wahl.

Das Problem als ich die fertige Anwendung deployen wollte

Die Entwicklung lief soweit streight-forward. Allerdings habe ich die Anwendung zum Testen nicht wirklich auf einen Webserver gestellt sondern in meinem lokalen Dateisystem installiert. Alle URLs im Webstart-Deskriptor waren deswegen der Art file:///home/matthias/source/zeiterfassung/… und funktionierten super. Die Ernüchterung kam erst als ich die Anwendung mit der endgültigen URL deployen wollte. Als Web-URL beginnt diese natürlich mit https://… und zu meinem Erschrecken macht das WELD Probleme:


Fehlermeldung/Exception in der Java-Konsole

WELD holt sich anscheinend die URL der Java-Archive vom Classloader um darin suchen zu können und der Classloader liefert für die Archive, obwohl er sie schon heruntergeladen hat die Originaladressen mit http://- oder https://-Präfix. Allerdings geht WELD davon aus, dass die URLs auf lokale Dateien zeigen. Bumm, es fliegt eine Exception und nichts startet.

Dokumentiert ist dieser Fehler seit einem guten Jahr als Bugticket WELD-1040 eine Bugfixrelease gibt es dafür jedoch noch nicht.

Workaround

Was tun, wenn ich die Anwendung zum Laufen bekommen will? Im Bugreport ist ein „proposed Fix” enthalten. Mir gefällt dieser Fix nicht wirklich. Es wird hier im FileSystemURLHandler von WELD einfach geschaut, ob eine URL mit „http:” oder „https:” beginnt und in diesem Fall die URL gegen die URL der gecachten Kopie im lokalen Dateisystem ausgetauscht. Das ganze funktioniert so nur ab Java 6, behebt nicht das eigentliche Problem, dass WELD nur spezielle URLs („file:”) versteht und hat sowieso keinerlei Fehlerbehandlung.

Aber gut, da die Anwendung im Moment nur von uns intern genutzt wird und sowieso Java 7 voraussetzt, habe ich mir die Sourcen von WELD besorgt, den Patch eingespielt nur mir selbst Pakete dafür gebaut.

Bleibt zu hoffen, dass der Fehler bald richtig und in einer offiziellen Release behoben wird. Immerhin ist im Bugticket „Fix Version/s: 2.0.0.CR1” gesetzt, das lässt hoffen.

Anmerkung: Wer im Bild oben genau hinschaut sieht, dass aus der URL http://example.com/ tatsächlich http:/example.com/ gemacht wird. Das ist kein Tippfehler in meinem Deskriptor sondern Teil des Verhaltens der ungepatchten Version.

Unless otherwise credited all material Creative Commons License by Matthias Wimmer