Applikationsserver WildFly 18 deckt aktuelle Enterprise-Java-Standards ab
Red Hats Java-Applikationsserver ist für Jakarta EE und Java EE 8 zertifiziert und arbeitet mit den Paketen von MicroProfile 3 zusammen.
- Rainald Menge-Sonnentag
Red Hat hat Version 18 des Java-Anwendungsservers WildFly veröffentlicht. Die Open-Source-Grundlage zu JBoss EAP (Enterprise Application Plattform) ist für die aktuellen Java-Enterprise-Standards zertifiziert und bietet eine erweiterte Anbindung für MicroProfile 3. Außerdem gibt es im Vergleich zum Vorgänger einige Verbesserungen für den Umgang mit Zertifikaten und den Einsatz im Cluster.
Jakarta und noch viel mehr
Für den im Juni veröffentlichten WildFly 17 hat Red Hat im September ein Update auf Version 17.01 nachgereicht, das die Zertifizierung für das kurz zuvor veröffentlichte Jakarta EE 8 mitbringt. Dass der Nachfolger ebenso Jakarta-EE-8-zertifiziert ist, versteht sich daher eigentlich von selbst. Die TCK-Ergebnisse (Technology Compatibility Kit) für die Full Platform und das schlankere Web Profile finden sich auf GitHub.
Auch für den Java-Enterprise-Vorgänger Java EE 8 ist WildFly zertifiziert. Zusätzlich implementiert der Anwendungsserver diejenigen APIs von MicroProfile 3, die nicht in Jakarta EE 8 enthalten sind: MP Config 1.3, MP Health Check 2.0, MP Metrics 2.0, MP OpenTracing 1.3 und MP Rest Client 1.3. Die inzwischen unter dem Dach der Eclipse Foundation gepflegte MicroProfile-Spezifikation war im Juni als 3.0-Release erschienen. Zu den ursprünglichen Initiatoren des vor allem auf Microservices ausgerichteten Standards gehören Red Hat und dessen neue Mutter IBM.
Security und Cluster
Jenseits der Anpassung an die Java-Enterprise-Standards hat WildFly 18 einige Verbesserungen bezüglich der Security an Bord, die sich vor allem der Zertifizierung widmen. Unter anderem lassen sich Zertifikate nun über das OCSP (Online Certificate Status Protocol) sperren beziehungsweise zurückziehen. Administratoren können zudem in der Kommandozeile mit den Befehlen ssl enable-ssl-management und ssl enable-ssl-http-server neuerdings Zertifikate von der offenen Zertifizierungsstelle Let's Encrypt beziehen.
Für eine automatische Optimierung im Cluster kann der Load Balancer nun die Route auf eine vordefinierte alternative Session weiterleiten, wenn die primäre inaktiv ist. Dazu lassen sich in der JSESSIONID mehrere Routen angeben und nach Präferenz sortieren.
JDK schlägt 13
Das WildFly-Team hat das aktuelle Release auf JDK 13 ausgelegt, also das jüngste der inzwischen halbjährlich veröffentlichten Java-Releases. Laut den eigenen Angaben läuft es insofern gut, als dass alle Testläufe der WilfFly Testsuite "nicht mehr als ein paar wenige Fehler in Bereichen, die vermutlich gewöhnlich nicht genutzt werden" ergeben.
Dennoch empfiehlt das Team den Einsatz der letzten Long-term-Support-Variante (LTS) JDK 11, da sich alle Tests darauf konzentrieren und bei WildFly die Stabilität im Zusammenspiel mit dem jeweils jüngsten LTS-Release im Vordergrund steht. Darüber hinaus lässt sich weiterhin Java 8 als Grundlage verwenden, was sich auch mindestens bis WildFly 21 nicht ändern soll.
Weitere Details zu WildFly 18 lassen sich der offiziellen Ankündigung entnehmen. Die vollständige Liste der Neuerungen und Änderungen ist in den Jira Relase Notes zu finden. Der Anwendungsserver lässt sich von der Download-Seite herunterladen, und der Source-Code liegt auf GitHub. (rme)
