Es grünt so grün: Eberhard Wolff über den Spring dm Server
Dieser Artikel wurde von Falk Hartmann geschrieben.
Falk ist leitet die Softwareentwicklung bei der Firma ubigrate. Sein besonderes Interesse gilt der modellgetriebenen Entwicklung in den Bereichen intelligente Geräte und Geräteintegration.
Am 2. April hatten wir Eberhard Wolff, Regional Director der SpringSource GmbH und bekannt als die treibende Kraft hinter dem Spring Framework bei uns wie angekündigt in Dresden zu Besuch. Es war das 6. Treffen unserer Java User Group, welches fast genau ein Jahr nach dem ersten Treffen (3. April 2008) stattfand.
Das diesmalige Treffen wurde von Saxonia Systems gesponsort – und das in einer Art und Weise, die nix zu wünschen übrig lies: der Umfang des Caterings war spektakulär, die Durchführung professionell – endlich einmal mußten wir hinterher nicht selber aufräumen (wobei es daran natürlich nie liegen soll). Herr Frank Anke, IT Consultant bei Saxonia, brachte uns in 10 Minuten seinen Arbeitgeber näher. Auch wenn ich mir ein paar mehr technische Details gewünscht hätte, war es ein interessanter Vortrag.
Eberhard vollbrachte mit seinem Vortrag mit dem Titel “Spring dm Server – Application Server der nächsten Generation” das Kunststück, eine OSGi-Einführung mit einer detaillierten Produktvorstellung inkl. eines Ausblicks auf Kommendes zu kombinieren. Der vorgestellte Spring dm Server ist in seinem Kern ein auf die OSGi-Implementierung equinox portierter Tomcat. Soweit, so gut, schließlich folgt der Spring dm Server damit nur einem Trend, der seit einem Jahr bei vielen Applikationsservern zu beobachten ist, Glassfish und Netweaver sind hier nur einige Beispiele.
Natürlich geht der Spring dm Server über die reine Portierung auf OSGi hinaus. Im wesentlichen wird versucht, die Modularisierbarkeit, welche den Reiz von OSGi ausmacht, auch Webapplikationen zugute kommen zu lassen. Die Versionierbarkeit der Bundles, welche OSGi bietet, weckt die Hoffnung, Schluß machen zu können mit dem mehrfachen Deployment von Standardkomponenten in Webapplikationen (ich sag hier nur mal Log4J!). Leider ist die Umsetzung dieser Idee nicht trivial, teilweise aus Gründen, die jedem Benutzer der OSGi-Plattform bekannt sind: manche Bibliotheken wie Hibernate etc. vertragen sich per se nicht mit OSGi. Ein Grund hierfür ist oft z.B. die Art und Weise, wie die Bibliotheken Klassen laden (Context ClassLoader, Class.forName etc).
Der Spring dm Server addressiert diese Schwierigkeiten auf seine ganz eigene Art und Weise. Es wird ein Mechanismus geboten, der das Deployment klassischer WARs in den Server unterstützt. Ein der Webapplication equivalentes Konzept wird durch sogenannte PAR-Files (beziehungsweise, ab Version 2.0, durch sogenannte Plan-Files) geboten. Sehr interessant fand ich, daß der Spring dm Server einen Mechanismus (“Cloning”) zum Umgehen von Class Loading Constraint Violations enthält.
Das Fazit unserer über 60 Teilnehmer war, soweit ich das beurteilen kann, sehr gut. Viele der Teilnehmer sind entweder im Web oder im OSGi-Umfeld aktiv. Für die letztere Fraktion kann ich natürlich am besten sprechen, schließlich adressiert auch unsere technologische Plattform einige der erwähnten Probleme und die Schwierigkeiten mit Log4J und Hibernate im OSGi-Container sind uns gut bekannt. Aus unserer Sicht wäre es natürlich wünschenswert, wenn generelle Verbesserungen an OSGi auch ihren Weg in neue OSGi-Spezifikationen finden würden – Eberhard verwies mich auf meine Frage hin auf die Bemühungen von SpringSource im OSGi-Konsortium, reklamierte natürlich auch das Recht für SpringSource auf Innovationen jenseits des per Spezifikation erreichbaren.
Eberhards grünes T-Shirt von der SpringOne harmonierte super mit der Grundfarbe der Fakultät Informatik, welche sonst im Allgemeinen als sehr gewöhnungsbedürftig empfunden wird. Vielleicht sollte sich die Informatik um die Austragung der SpringOne bemühen? 
