Apache DeltaSpike: Vereinigung der CDI-Communitys

Im selben Boot

Gerhard Petracek

Im Dezember 2011 wurde Apache DeltaSpike aus der Taufe gehoben. Dieses junge Projekt vereint nicht nur Funktionalitäten bewährter CDI-Erweiterungen wie Apache MyFaces CODI und JBoss Seam3, sondern auch die dazugehörigen Communitys. Deren gemeinsames Ziel ist es, praxiserprobte und innovative Konzepte für CDI-Erweiterungen zu entwickeln, die in Kombination mit möglichst vielen Laufzeitumgebungen für CDI-basierte Applikationen getestet sind.

Mit CDI (Contexts and Dependency Injection for the Java EE platform) [1] hielt Ende 2009 eine neue Technologie Einzug in die Java-EE-Plattform. Die Spezifikation beruht sowohl auf altbewährten Konzepten aus dem Open-Source-Bereich als auch auf innovativen Mechanismen. Eine sehr leistungsfähige Funktionalität hält sich jedoch eher im Hintergrund und ist daher Vielen unbekannt. Die Rede ist von einem umfangreichen SPI (Service Provider Interface). Durch dieses lässt sich CDI erweitern und eigene Konzepte integrieren. Die daraus resultierenden CDI Extensions sind portabel und können dadurch mit allen spezifikationskonformen CDI-Implementierungen verwendet werden, ohne dass auf proprietäre Konfigurationen der verschiedenen Implementierungen (oder Applikationsserver) zurückgegriffen werden muss. Dieser Vorteil wurde von der Community schnell erkannt [2], und es entstanden nach kurzer Zeit einige Projekte, die solche CDI Extensions zur Verfügung stellten.

Neben erfolgreichen Projekten wie Apache MyFaces ExtCDI (auch bekannt als MyFaces CODI [3]) und JBoss Seam3 [4] gibt es einige kleinere CDI-Erweiterungen und unzählige Blog-Beiträge über die Erweiterungsmöglichkeiten von CDI von sehr unterschiedlicher Qualität. Dies stellt einige User vor komplexe Entscheidungen. Unter anderem sorgte Seam3 anfangs für Verwirrung, da es sich hierbei um ein neues Produkt handelt, das aus technischer Sicht keine direkte Fortführung von Seam2 ist. Für einige Applikationen ist daher ein oftmals unerwartet hoher Migrationsaufwand entstanden. MyFaces CODI wurde parallel dazu oft als aufstrebende Alternative gesehen. Durch innovative Konzepte, hohe Stabilität und eine hohe Kompatibilität [5] mit aktuellen Java-EE-5/6-Laufzeitumgebungen wurde MyFaces CODI schnell bekannt. Das Anfang 2010 gestartete Projekt kann, wie durch die CDI-Spezifikation vorgesehen, sowohl mit verschiedenen CDI-Implementierungen als auch mit anderen portablen CDI-Erweiterungen, wie etwa Seam3, eingesetzt werden. In der Praxis entscheiden sich viele User dennoch für eine der verfügbaren Erweiterungen, statt mehrere zu kombinieren.

Die Community vereinigt sich

Statt eine Kombination verschiedener CDI-Erweiterungen – beispielsweise durch eine umfangreiche Dokumentation – zu erleichtern und Tests für verschiedene Konstellationen zu erstellen, entschied sich ein großer Teil der Community dazu, ein gemeinsames Projekt zu starten. Vor allem wegen ihrer Herstellerunabhängigkeit und ihres Communityschwerpunkts wurde die Apache Software Foundation (ASF) für dieses neue Projekt ausgewählt. Unter dem vorläufigen Namen DeltaSpike wurde im so genannten Incubator, dem Eintrittspunkt für alle neuen ASF-Projekte, im Dezember 2011 dieses neue Projekt gestartet. Nach der Einrichtung der Infrastruktur, wie beispielsweise dem Git Repository [6], wurde mit einigen grundlegenden Diskussionen begonnen. Herrscht bei einem Thema keine Einstimmigkeit, so werden Entscheidungen nach einer entsprechenden Diskussion durch einen Mehrheitsbeschluss getroffen. Jeder ist willkommen, an diesen konstruktiven Diskussionen teilzunehmen bzw. Feedback zu geben.

Derzeit werden Teile aus MyFaces CODI, JBoss Seam3 und anderen CDI-Erweiterungen durch deren ursprüngliche Communitys fusioniert. Dabei werden alle Bereiche einem genauen Review unterzogen und die besten Konzepte ausgewählt. Bei diesem Prozess werden Implementierungen übernommen und bei Bedarf geändert oder erweitert. Da die zugrunde liegenden Projekte bereits einen Reifeprozess durchlaufen haben, jedoch auf Rückwärtskompatibilität Wert legen mussten, gibt es natürlich auch Teile, die etwas anders angegangen werden müssen. Diese Chance nimmt die Community wahr: Einige Bereiche werden nochmals hinterfragt und bei Bedarf sogar neu implementiert. In den zugrunde liegenden Projekten gab es bisher teilweise sehr unterschiedliche Ansätze. In solchen Fällen werden die ursprünglichen Anwendungsfälle analysiert. Dann wird auf Basis bisheriger Erkenntnisse ein neues API erstellt. Dabei legt das Entwicklerteam großen Wert auf Feedback aus der gesamten Community. Auch konstruktive Kritik zum bestehenden API ist willkommen, da sich dieses auf Basis von neuen Erkenntnissen und den entsprechenden Diskussion auf der Mailingliste [7] bis zu Version 1.0 ändern kann. Statt später einen unnötig hohen Migrationsaufwand zu riskieren, ist es sinnvoll, früh an den Diskussionen teilzunehmen oder zumindest eine Rückmeldung zu geben, falls die fusionierten Funktionalitäten einen bestimmten Anwendungsfall nicht (mehr) unterstützen. In der Regel reagiert das Entwicklerteam schnell, und sofern die gewünschte Funktionalität nicht bereits durch einen besseren Ansatz zur Verfügung steht, wird mit der Arbeit für eine entsprechende Lösung zügig begonnen. Um Feedback zu vereinfachen, sind im Wiki die vorerst finalisierten Funktionalitäten dokumentiert.

Neben einer guten Dokumentation und vielen Beispielen ist die regelmäßig getestete Kompatibilität mit verschiedenen Laufzeitumgebungen für CDI-Applikationen ein wichtiges Ziel. Auf Basis von JBoss Arquillian [8] wird eine umfangreiche Test-Suite erstellt, die von mehreren Continuous-Integration-(CI-)Servern regelmäßig mit diversen Laufzeitumgebungen ausgeführt wird.

Aktueller Stand

Nur Teile, die aus der Sicht des Entwicklerteams für User verwendbar sind, werden im Wiki dokumentiert. Etwas später ist ebenfalls eine Dokumentation geplant, die auch offline zur Verfügung steht. Die Community hat sich für frühe Releases in kurzen Abständen entschieden, und so wurde bereits zwei Monate nach der ersten E-Mail auf der Mailingliste Version 0.1-incubating releast. Für weitere Releases gibt es keinen fixierten Zeitrahmen. Ähnlich wie bei MyFaces CODI ist es derzeit jedoch geplant, etwa alle zwei Monate eine neue Version herauszugeben. Daher hält Version 0.1 noch nicht sehr viel für Anwendungsentwickler bereit. Jedoch wird der Funktionsumfang laufend erweitert, und für Version 0.2-incubating sind weitere Module sowie neue Funktionalitäten für den Core in Arbeit. Der genaue Umfang ist vom Fortschritt der Diskussionen zu den einzelnen Funktionalitäten abhängig.

Mit Apache OpenWebBeans [9] und JBoss Weld [10] gibt es zwei CDI-1.0-Implementierungen, die auch Java SE unterstützen. Da es mit diesen Implementierungen bereits jetzt möglich ist, CDI außerhalb von Java-EE-Projekten zu verwenden, konzentrieren sich die ersten beiden Releases auf Funktionalitäten, die ebenfalls in Java-SE-Applikationen verwendet werden können. Vor allem vor Version 1.0 können Releases dadurch auch Zwischenstände enthalten. Dokumentierte und getestete Funktionalität sollte sich, wenn überhaupt, nur in Ausnahmenfällen grundlegend ändern. Somit steht einem frühen Einsatz von DeltaSpike beispielsweise für Fallstudien nichts im Weg. Von Anfang an wird durch entsprechende Tests versucht, eine hohe Qualität sicherzustellen, jedoch ist es empfehlenswert, wegen eventueller API-Änderungen den möglichen Einsatz in produktiven Projekten sorgfältig zu evaluieren bzw. Rücksprache mit der Community zu halten, um spätere Aufwände bei der Umstellung auf Version 1.0+ möglichst gering zu halten. Denn Änderungen sind, wie bereits erwähnt, vor allem auf Basis von Community-Feedback möglich.

Auswirkungen auf bestehende Projekte

Grundsätzlich ist geplant, dass möglichst viele Funktionalitäten der ursprünglichen Extension-Projekte in DeltaSpike aufgenommen werden. Allerdings ist dies von den Entscheidungen der Community abhängig. Hierbei steht vor allem die Portabilität im Vordergrund. So wurde aus JBoss Solder, einer der zentralen Bestandteile von Seam3, die Annotation @Requires nicht in DeltaSpike übernommen, weil die geforderte Portabilität nicht möglich war. Eine weitere Annotation namens @DefaultBean wurde durch einen komplett neuen Ansatz ersetzt, um die zugrunde liegende Komplexität zu reduzieren. Die entsprechenden Details und Begründungen sind im Wiki dokumentiert und können somit jederzeit nachvollzogen werden.

Die MyFaces-Community hat darüber hinaus angekündigt [11], dass MyFaces CODI und DeltaSpike auch parallel in einer Applikation verwendet werden können, um eine möglichst sanfte Migration zu ermöglichen. Sollten wichtige Funktionalitäten von MyFaces CODI nicht in DeltaSpike verfügbar sein, so wird es eine Version 2.0 von MyFaces CODI geben. Diese Version würde auf DeltaSpike aufbauen und die fehlenden Funktionalitäten zur Verfügung stellen. Das aktuelle Ziel ist jedoch eine vollständige Überführung des Funktionsumfangs, wodurch eine Version 2.0 nicht mehr nötig wäre. Für Konzepte aus MyFaces CODI, die etwa durch die Zusammenführung mit Funktionalitäten anderer CDI Extensions erweitert oder geändert werden, ist kurz nach Version 1.0 von DeltaSpike eine Anleitung für die Migration auf das neue API geplant.

Aber auch weit vor Version 1.0 von DeltaSpike gibt es positive Auswirkungen auf andere Projekte. So wurde DeltaSpike auch mit kürzlich erschienenen Applikationsservern getestet und anschließend erweitert, um die Portabilität mit diesen neuen Servern sicherzustellen. Die entsprechenden Verbesserungen wurden anschließend auch in MyFaces CODI übernommen. Einer dieser Server ist Apache TomEE [12]. Die nächste Betaversion von TomEE enthält kleine, aber wichtige Bugfixes, die Probleme mit portablen CDI Extensions beseitigen. Um die aktuelle Kompatibilität weiterhin sicherzustellen, werden durch CI-Server bei Apache täglich die Integrationstests mit TomEE ausgeführt. Für andere Server erfolgt dies durch Freiwillige in der Community.

Bei der Erstellung verschiedener Testkonstellationen reizt DeltaSpike auch Arquillian aus und stößt an dessen Grenzen. Nach Rücksprache mit den Hauptentwicklern von Arquillian wird eine der kommenden Versionen die benötigten Funktionalitäten zur Verfügung stellen, wodurch Arquillian auch für Tests anderer Applikationen noch flexibler wird.

Auch die unterstützten CDI-Implementierungen profitieren von DeltaSpike. Da Entwickler von OpenWebBeans und Weld ebenfalls an DeltaSpike mitarbeiten, werden unterschiedliche Verhaltensweisen dieser Implementierungen analysiert und entsprechende Fehler behoben.

Bei einem zu großen Interpretationsspielraum in der CDI-Spezifikation selbst wird die entsprechende Passage mit der Expert Group für CDI besprochen und für zukünftige Versionen klargestellt. Darüber hinaus werden beispielsweise einige Funktionalitäten für die nächste CDI-Version mit der gesamten Community diskutiert und, wenn möglich, sogar in DeltaSpike für CDI 1.0 implementiert, damit DeltaSpike-User diese Funktionalitäten bereits vor der nächsten CDI-Version verwenden können.

Geschrieben von
Gerhard Petracek
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.