Mit dem Red Hat JBoss EAP 8 steht ein Major-Upgrade des Applicationservers mit vielen herausfordernden Änderungen bevor. Als der führende Red Hat JBoss EAP Partner in Österreich haben wir bereits Erfahrungen mit diesem speziellen Upgrade gesammelt und können dir das Upgrade abnehmen. #simplifyYourBusiness.
Bereit für den Sprung in eine einfachere Zukunft?
#simplifyYourBusiness: Wir teilen unser Wissen zu den Themen Software-Modernisierung und Entwicklung
Video-Transkript hier.
Welche Herausforderungen hat das EAP8 Upgrade für dich?
Was bringt dir ein EAP8 Upgrade?
Der wichtigste Vorteil eines Upgrades ist, dass man damit auf die aktuelle, am besten unterstützte EAP-Version wechselt. Und nach dem Upgrade voraussichtlich wieder ein paar Jahre Sicherheit.
In den EAP8-Beta Releasenotes sind über 30 neue Features aufgeführt. Welche Features am hilfreichsten sind, kommt auf die jeweilige Umgebung und die Anforderungen an. Hier ein paar Highlights:
Warum mit Gepardec?
Ergebnisse
So funktionierts
Willst du Zeit und Geld beim Upgrade sparen?
Wir freuen uns auf deine Kontaktaufnahme.
+
Einleitung & persönlicher Hintergrund
Ich beschäftige mich seit ungefähr 2005 mit JBoss – seit 2010 dann intensiver. Seitdem halte ich auch Trainings zu JBoss EAP.
Wir haben in den letzten Jahren mehrere interne Projekte sowie ein Kundenprojekt auf eine neue Version upgegradet. Wie Chris bereits erwähnt hat, möchte ich heute ein wenig darüber erzählen, was wir gemacht haben, wie wir es gemacht haben und wo aus unserer Sicht die größten Probleme liegen.
Ich bin dabei eher der Techniker – im Gegensatz zu Chris, der aus Innovations- und Marketingperspektive kommt. Teilweise ist vielleicht der Eindruck entstanden, dass man für ein JBoss-Upgrade einen „Meister“ braucht. Ob es wirklich ein Meister sein muss, sei dahingestellt – aber ein bisschen Erfahrung sollte man definitiv mitbringen. Ein Geselle ist gut, ein Lehrling alleine wäre mir ehrlich gesagt zu riskant.
Begriffsklärung: JBoss EAP & WildFly
Was auf dieser Folie steht, wissen die meisten vermutlich bereits – trotzdem kurz zur Einordnung:
JBoss EAP steht für Enterprise Application Platform. Es handelt sich um einen Java Enterprise (ab Version 8: Jakarta) Application Server von Red Hat.
Wie bei allen Red-Hat-Produkten basiert auch JBoss EAP auf einem Open-Source-Projekt – konkret auf WildFly.
Die aktuelle WildFly-Version war (Stand gestern) 7.4.14, zusätzlich gibt es bereits eine 8.0 Beta.
In diesem Webinar geht es darum, wie man von WildFly 7.4 oder älteren Versionen auf Version 8.0 migriert. Die finale 8.0-Version ist zum Zeitpunkt dieses Vortrags noch nicht veröffentlicht – wir warten alle darauf.
Warum überhaupt upgraden?
Vielleicht fragen sich einige: Warum sollte ich überhaupt upgraden?
Meine ehrliche Antwort: Man hat langfristig keine echte Alternative.
Die Welt dreht sich weiter – Standards ändern sich, Sicherheitslücken werden entdeckt, Patches kommen.
Wenn man auf alten Versionen bleibt, kann man Patches nicht mehr einfach einspielen, weil jedes Upgrade dann plötzlich ein großer, aufwendiger Schritt wird.
Der wichtigste Grund für ein Upgrade ist für mich daher:
Upgrades frühzeitig angehen, um später handlungsfähig zu bleiben.
Ein weiterer Grund ist der Support:
Support gibt es nur für aktuelle Versionen.
Neue Features sind für mich persönlich der weniger wichtige Grund. Beim Upgrade geht es nicht primär um neue Funktionen, sondern darum, auf einer unterstützten, sicheren Version zu bleiben.
Support-Situation bei Red Hat
Die aktuelle Support-Version ist JBoss EAP 7, verfügbar seit 2016.
-
Der Full Support ist offiziell bereits ausgelaufen (eventuell verlängert – Details sind nicht ganz klar).
-
Maintenance Support (Bugfixes, kleinere Anpassungen) läuft noch bis Juni 2025.
Das bedeutet:
Man muss nicht sofort upgraden, sobald EAP 8 final erscheint – es bleibt noch etwa eineinhalb Jahre Zeit.
Zusätzlich gibt es:
-
Extended Life Cycle Support 1 & 2
-
Im „Worst Case“ Support noch bis November 2029
Und was ist mit WildFly ohne Red Hat?
Wer statt JBoss EAP direkt WildFly nutzt, hat im Grunde dieselben Themen – nur ohne kommerziellen Red-Hat-Support.
Stattdessen verlässt man sich auf Community Support.
Auch hier gilt:
Die Community ist wenig begeistert, wenn sehr alte Versionen im Einsatz sind. Häufig lautet die Antwort dann:
„Bitte zuerst auf die aktuelle Version upgraden – dann reden wir weiter.“
Die Themen rund um das Jakarta-Upgrade betreffen übrigens nicht nur JBoss oder WildFly, sondern genauso:
-
WebLogic
-
WebSphere
-
Quarkus
-
und andere Jakarta-basierte Application Server
JBoss EAP 8: Ein Major Upgrade
JBoss EAP 8 ist ein Major Upgrade – das bedeutet:
-
Es gibt inkompatible Änderungen
-
Und zwar nicht zu knapp
Die größte Änderung – und vermutlich der Hauptgrund, warum viele heute hier sind:
JBoss EAP 8 unterstützt Jakarta EE 10
Damit kommt erstmals die große Namespace-Änderung:
-
javax.*→jakarta.*
Diese Änderung entstand, weil Oracle Java EE an die Eclipse Foundation übergeben hat.
Nach einigen Diskussionen und rechtlichen Fragen mündete das Ganze in der Umbenennung der Namespaces.
Weitere relevante Änderungen
Neues Security Subsystem: Elytron
Seit JBoss 7.1 gibt es ein neues Security Subsystem namens Elytron.
-
Bisher liefen Legacy Security und Elytron parallel
-
Ab Version 8 wird nur noch Elytron unterstützt
Das kann ebenfalls für Kopfzerbrechen sorgen – ist aber meist nicht das größte Problem.
Das eigentliche Problem: Realität im Code
Ich halte seit rund zehn Jahren JBoss-Trainings. Dafür verwende ich eine Beispielapplikation namens „Ticket to Rock“ – ursprünglich geschrieben als Demo für ein EJB-Buch.
Diese Applikation:
-
existiert seit 2012
-
hatte bis 2023 nur ca. 8 Zeilen Code-Änderung
-
lief über 10 Jahre praktisch wartungsfrei
Nach dem Upgrade auf Jakarta:
-
ca. 800 Code-Änderungen
Das zeigt deutlich:
Die bisherige Stabilität und Abwärtskompatibilität von Java EE / Jakarta EE ist hier massiv gebrochen worden.
Das größte Risiko: Dependencies
Solange man den Source Code selbst kontrolliert, ist das Problem lösbar.
Aber:
-
Jede Applikation verwendet externe Dependencies
-
Manche davon sind nicht mehr gewartet
Ein konkretes Beispiel:
-
Eine Test-Dependency namens EasyMock (nur als Beispiel)
-
Letztes Release: vor 14 Jahren
-
Funktioniert wegen der Namespace-Änderung nicht mehr
Hier wird es kritisch:
Wenn eine stark genutzte Dependency nicht mehr gepflegt wird, kann das Upgrade extrem problematisch werden.
Das ist aus meiner Sicht das größte Risiko bei Migrationen.
Zweites großes Risiko: fehlendes Wissen & Tests
Viele Applikationen:
-
laufen stabil
-
werden kaum mehr angefasst
-
niemand kennt sich wirklich aus
-
Testabdeckung ist schlecht oder fehlt
Dann weiß man beim Upgrade nicht:
-
Was muss getestet werden?
-
Wo lauern versteckte Probleme?
Gute, automatisierte Tests sind hier der Schlüssel, um Risiko und Aufwand niedrig zu halten.
Warum das Ganze so mühsam ist
Auf den ersten Blick scheint es einfach:
„Ersetze javax durch jakarta“
Leider stimmt das nicht.
Beispiele:
-
javax.inject.Inject→jakarta.inject.Inject -
aber:
javax.naming.Contextbleibtjavax.naming.Context
Ein globales Search & Replace funktioniert also nicht.
Dasselbe gilt für Maven-Dependencies:
-
Namen ändern sich
-
Gruppen ändern sich
-
Artefakte ändern sich
-
manchmal alles gleichzeitig
Beispiel:
-
Jackson:
-
neue Group
-
neuer Artefaktname
-
neue Imports
-
neue Fully Qualified Class Names
-
Andere Projekte (z. B. OpenAPI Generator) lösen es eleganter – per Konfigurationsoption.
Ergebnis:
Man muss für jede Dependency einzeln recherchieren, wie das jeweilige Projekt mit Jakarta umgeht.
Weitere Migrationsthemen
-
Swagger → OpenAPI
Swagger unterstützt kein Jakarta EE 10 mehr.
Das bedeutet oft eine zusätzliche Migration. -
Deployment Descriptors
(web.xml,persistence.xml,beans.xml):
Neue Namespaces & Versionen – meist unkritisch, aber sauber umzusetzen. -
JPA-Änderungen
Bestimmte Queries funktionieren nicht mehr zur Laufzeit (kein Compiler-Fehler!).
Beispiel:from Entity→select e from Entity e
Auch hier gilt: Tests sind entscheidend.
Tools, die helfen
Windup
-
Analyse-Tool von Red Hat
-
Findet potenzielle Probleme
-
Liefert Reports mit Aufwandsschätzung
-
Macht keine automatischen Änderungen
OpenRewrite
-
Open-Source-Tool
-
Passt Source Code & POMs automatisch an
-
Erhält größtenteils die Formatierung
-
Viele fertige „Rezepte“
-
Von Red Hat aktiv für Jakarta-Migration genutzt
Diese beiden Tools lassen sich gut kombinieren und wurden auch in unseren Projekten erfolgreich eingesetzt.
Zusätzlich hilfreich:
-
Nexus / Artifact Repository
-
Maven Dependency Tree
-
Kommandozeilen-Tools (
grep,ripgrep) -
und ganz wichtig: Erfahrung
Vorgehensweise für eine erfolgreiche Migration
Bewährt hat sich:
-
Zwei Teams:
-
Migration & Tooling-Know-how
-
Applikations-Know-how
-
-
Kleine, iterative Schritte:
-
Analyse
-
Teilmigration
-
Testen
-
Nachjustieren
-
erneut migrieren
-
-
Ziel:
-
Code so vorbereiten, dass automatische Migration vollständig durchläuft
-
danach aufräumen & finalisieren
-
Abschluss
Es gäbe noch weitere Themen (z. B. Security mit Elytron), aber zeitlich belassen wir es dabei.
Das Recording, die Folien und weitere Materialien bekommt ihr per E-Mail.
Wenn ihr euer Upgrade möglichst reibungslos angehen wollt:
Wir haben die Erfahrung, kennen die Stolperfallen und unterstützen euch gerne.
Vielen Dank für eure Zeit und eure Aufmerksamkeit.
Ich freue mich, wenn wir uns bei dem einen oder anderen JBoss-Upgrade wiedersehen.