JBoss EAP 8 Upgrade - Erste Erkenntnisse

Teil 1: Warum kümmert mich das?

EAP Upgrades

Während der vergangenen 10 Jahre waren auch major Upgrades des JBoss Application Servers (JBoss EAP)  eher unspektakulär. Der letzte große Schritt war 2012 der Umstieg von EAP 5 auf EAP 6, mit der Änderung der Administrationsarchitektur. Jetzt steht wieder ein größerer Sprung mit, wie es derzeit scheint, zwei größeren Themen an:

• JEE 8 nach Jakarta 10
• Legacy Security Subsystem wird nicht mehr unterstützt

Darüber hinaus sind in den Release-Notes von JBoss EAP 8.0 Beta weitere Änderungen aufgeführt, die uns aber nicht so gravierend erscheinen. Wir werden sehen.

Jakarta 10

Durch die Übergabe der Java Enterprise Edition (JEE) von Oracle an die Eclipse Foundation erfolgte nicht nur eine Namensänderung auf Jakarta Enterprise Edition, sondern es wurden auch die javax.* Namespaces der Enterprise Edition auf  jakarta.* geändert. Das bedeutet, dass praktisch in allen Applikationen Sourcen geändert werden müssen. Applikationen, die unter Umständen seit über einem  Jahrzehnt unverändert laufen, müssen geändert und neu kompiliert werden. Das kann zur Herausforderung werden.

Elytron Security Subsystem

Das Elytron Security Subsystem gibt es schon seit EAP 7.1. Allerdings wurde parallel das vorherige, jetzt “Legacy”, Security Subsystem noch unterstützt. Da Elytron bisher doch etwas komplexer zu konfigurieren war als das Legacy Security Subsystem, wird es unserer Erfahrung nach oft noch nicht eingesetzt. Daher erwarten wir hier etwas Lern- und Umstellungsaufwand.

Mal Schauen!

Aber was heißt das in der Praxis? Ist eh alles nicht so wild oder sind noch Fallen versteckt, die wir noch nicht sehen? Probieren wir es einfach mal aus. JBoss EAP 8 ist zwar noch nicht released, wir vermuten mal, im Herbst wird es soweit sein, aber es gibt eine JBoss EAP 8 Beta. Gut genug, um erste Erfahrungen zu sammeln.

Für unser Training JBoss Administration haben wir etliche kleine Beispiele und Applikationen, die viele Aspekte des Servers abdecken. Diese wollen wir auf EAP 8 migrieren. Interessierte nehmen wir gerne mit auf unsere Reise, die wir in den nächsten Wochen hier beschreiben wollen.

Teil 2: Erste Versuche

Installation

Wie in Teil 1  dargestellt, versuchen wir unser Training JBoss Administration auf EAP 8 zu heben. Als Aufwandsminimierer verwende ich zur Installation das ZIP-Paket des Servers. Wie üblich von der Red Hat Downloads Seite runterladen, auspacken und starten. Soweit keine Überraschungen.Das erste Beispiel ist eine ganz einfache JSP-Applikation, die als exploded Deployment installiert wird. Funktioniert problemlos. Zeit, unsere JBoss Setup Skripts zu testen, mit denen wir alle Übungen im Training automatisiert haben. Ein JSP-Beispiel (ja, einige Beispiele sind in die Jahre gekommen) lässt sich problemlos deployen und es funktioniert. 

Security

Das nächste Beispiel, das wir angehen, ist ein einfaches Security-Beispiel. Hier werden User und Rollen in eigenen Dateien abgespeichert, ansonsten soll Security genauso funktionieren, als hätten wir die User über add-user.sh hinzugefügt. Das „Legacy“ Security-Subsystem ist nicht mehr verfügbar. Zum Glück gibt es gute Dokumentation auf der Red Hat-Webseite, so konnten wir unser Config-Skript leicht auf Elytron umstellen:

Vorher:

/subsystem=security/security-domain=myapps:add(cache-type=default)
/subsystem=security/security-domain=myapps/authentication=classic:add(\
  login-modules=[ \
    {"code" => "Remoting","flag" => "optional","module-options" => [\
      ("password-stacking" => "useFirstPass")]},\
    {"code" => "RealmUsersRoles","flag" => "required","module-options" => [\
      ("usersProperties" => "${jboss.server.config.dir}/myapps-users.properties"),\
      ("rolesProperties" => "${jboss.server.config.dir}/myapps-roles.properties"),\
      ("realm" => "ApplicationRealm"),("password-stacking" => "useFirstPass")]}])

Nachher:

/subsystem=elytron/properties-realm=MyAppsRealm:add(\
  users-properties={\
    path=myapps-users.properties,relative-to=jboss.server.config.dir},\
  groups-properties={\
    path=myapps-roles.properties,relative-to=jboss.server.config.dir})
/subsystem=elytron/security-domain=myapps:add(\
  default-realm=MyAppsRealm,permission-mapper=default-permission-mapper,realms=[\
    {realm=MyAppsRealm,role-decoder=groups-to-roles}])
/subsystem=undertow/application-security-domain=myapps:add(\
  security-domain=myapps)

Statt des LoginModuls RealmUsersRoles, haben wir einen Security Realm properties-realm konfiguriert. Nach der Änderung hat das Beispiel ohne weitere Anpassungen funktioniert. So kann es weiter gehen!

Wo sind die Sourcen?

Etwas euphorisch gehen wir das nächste Beispiel an. Eine Mini-Applikation mit einem Servlet, um Logging und Log-Levels zu demonstrieren. Deployed problemlos, aber beim Test: HTTP/1.1 403 Forbidden

Das ist jetzt nicht ganz unerwartet. Servlets verwenden javax.servlet.* Klassen; die werden wir wohl umschreiben müssen. Das Beispiel ist unverändert aus dem Jahr 2015, aber die Sourcen sind sicher noch irgendwo. Ganz sicher. In jboss-examples oder in einem meiner Source-Ordner am Laptop. Einige Zeit später gebe ich die Suche auf und entschließe mich, das kleine Beispiel neu zu schreiben. Ist eh nur eine Klasse, zahlt sich nicht aus länger zu suchen. Im “echten Leben”, abseits von einfachen Trainingsbeispielen, kommt das sicher auch nicht vor, dass jemand Sourcen nicht wiederfindet. Sicher nicht.

Aber bevor ich das Logging-Beispiel neu schreibe, probieren wir das Datenbank-Beispiel. Die Applikation dahinter, TicketMonster, ist etwas komplexer. Irgendwer bei Red Hat oder vom JBoss-Team hat die mal geschrieben. Seit 2016, mit EAP7, verwenden wir sie im Training. Da gibt es sicher wo Sourcen. Ganz sicher. Nur wenige Stunden später und nach Auschecken verschiedenster Versionen der TicketMonster Applikation, finde ich tatsächlich einen Branch von Tomaz Cerar mit halbwegs passenden Sourcen. Den klonen wir und bringen ihn erst mal auf EAP 7 zum Laufen. Das ist wenigstens ein versöhnlicher Zwischenstand.

Hier gehts zu Teil 3 & 4