Applikationsserver WildFly 25 ist bereit für Java SE 17

Die aktuelle Version schließt auch den Übergang zu einem vollständig auf dem Security-Framework Elytron basierten Security-Layer ab.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 2 Min.
Von
  • Matthias Parbel

Das von Red Hat unterstützte Entwicklerteam hinter dem Java-Anwendungsserver WildFly hat Version 25 vorgelegt. Das neue Release bringt eine Reihe weiterer Anpassungen an die verschiedenen Long-term-Support-Versionen von Java SE – einschließlich des neuesten Java SE 17. Bei dem als Open-Source-Grundlage zu JBoss EAP (Enterprise Application Platform) dienenden Applikationsserver ist nun auch der Umbau auf das Security-Framework Elytron komplett vollzogen.

Während WildFly 25 standardmäßig nach wie vor eine zu Jakarta EE 8 kompatible Implementierung ist, kam bei den Anpassungstests an die LTS-Versionen von Java SE in der Previewphase auch schon das Technology Compatibility Kit (TCK) von Jakarta EE 9.1 zum Einsatz. Neben SE 11 und SE 8 können Entwicklerinnen und Entwickler das neue Release daher nun auch mit Java SE 17 nutzen. Dabei gilt es jedoch zu beachten, dass die JVM Reflective Calls zurückweisen wird, bei denen unter SE 11 nur eine Warnung erschiene. Um den Zugriff in Java-SE-17-Instanzen zu ermöglichen, sind einige Anpassungen in der JPMS-Konfiguration erforderlich, sofern nicht Bootable Jars oder angepasste Launch-Skripte zum Einsatz kommen:

--add-exports=java.desktop/sun.awt=ALL-UNNAMED

--add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED

--add-opens=java.base/java.lang=ALL-UNNAMED

--add-opens=java.base/java.lang.invoke=ALL-UNNAMED

--add-opens=java.base/java.lang.reflect=ALL-UNNAMED

--add-opens=java.base/java.io=ALL-UNNAMED

--add-opens=java.base/java.security=ALL-UNNAMED

--add-opens=java.base/java.util=ALL-UNNAMED

--add-opens=java.base/java.util.concurrent=ALL-UNNAMED

--add-opens=java.management/javax.management=ALL-UNNAMED

--add-opens=java.naming/javax.naming=ALL-UNNAMED

Als Ablösung für den bereits als veraltet (deprecated) markierten Legacy-Security-Layer steht seit WildFly 11 eine auf dem Security-Framework Elytron aufbauende Alternative zur Verfügung. Mit dem Übergang zu Java SE 17, dem die für Legacy Security erforderlichen Packages fehlen, vollzieht das Entwicklerteam nun auch die Ablösung der alten Sicherheitsstruktur und macht Elytron zum Standard. Damit entfallen unter anderem die security-realm-Elemente in den Konfigurationsdateien. Auch der auf PicketBox basierende Sicherheitsspeicher für Credentials wird durch die von Elytron bereitgestellten Ressourcen ersetzt.

Weitere Details zu den Neuerungen in WildFly 25 finden sich in den Release Notes. Ein separater Blogbeitrag liefert darüber hinaus einen Ausblick auf die für kommende Versionen geplanten Änderungen am Applikationsserver.

(map)