Technische Grenzen
Die Legacy-Anwendung ist über viele Jahre gewachsen. Ihre technischen Grenzen erklären, weshalb die Modernisierung nicht als einzelnes Versionsupgrade durchgeführt werden kann.
Nicht mehr unterstützte Plattform
Tomcat 7, Java 8 und mehrere eingesetzte Frameworkversionen sind veraltet oder nicht mehr regulär unterstützt. Sicherheitskorrekturen, aktuelle Werkzeuge und neue Bibliotheksversionen lassen sich deshalb nur eingeschränkt nutzen.
Die Anwendung basiert vollständig auf dem alten javax.*-Namensraum. Moderne Spring-Boot- und Jakarta-Versionen verwenden dagegen jakarta.*. Dieser Wechsel betrifft Servlet, Persistence, Validation, Mail und weitere APIs gleichzeitig.
Oberfläche
JSF, RichFaces und Dojo sind eng mit den serverseitigen Controllern, Templates und Ressourcen verbunden. RichFaces wird außerdem außerhalb der UI als JSON-Bibliothek verwendet. Eine reine Aktualisierung einzelner Frontend-Bibliotheken würde diese Kopplung nicht beseitigen.
Deshalb wird die Legacy-Oberfläche nicht in den neuen Jakarta-Stack übernommen. Das Ziel ist eine eigenständige Vue-3-Anwendung, die über dokumentierte HTTP-APIs mit dem Backend kommuniziert.
Frameworkkopplung
Die Fachlogik verwendet teilweise Typen und Erweiterungspunkte aus JSF, RichFaces, Jersey, CDI und Hibernate. Besonders interne Jersey-Klassen und statische CDI-/JPA-Hilfen erschweren unabhängige Tests und Framework-Upgrades.
Vor dem Plattformwechsel müssen fachliche Services deshalb von Web-, Container- und Persistenzinfrastruktur getrennt werden.
Build und Reproduzierbarkeit
Der ANT-Build, lokale JAR-Sammlungen und die eingecheckte Dojo-Distribution machen den Build zwar weitgehend unabhängig von externen Repositories, aber nur eingeschränkt nachvollziehbar und wartbar. Unklare Artefaktherkunft und manuell gepflegte transitive Abhängigkeiten erhöhen das Risiko von Versionsabweichungen.
Der erste Schritt von BFlies Next ersetzt diese Mechanik durch Maven und kontrollierte Nexus-Repositories, ohne das Laufzeitverhalten bereits zu verändern.
Testabdeckung
Im Legacy-Projekt existiert keine nennenswerte automatisierte Testabdeckung. Dadurch kann ein technisch erfolgreicher Build fachliche oder laufzeitbezogene Abweichungen nicht ausschließen. Die Migration stützt sich daher auf:
- gezielte Unit- und Charakterisierungstests für entkoppelte Fachlogik,
- den Vergleich der erzeugten WAR-Inhalte,
- dokumentierte manuelle Abnahmen der zentralen Nutzerabläufe,
- den eingefrorenen Legacy-Stand als Verhaltensreferenz.
Datenbank und Authentifizierung
Schema-Updates, fachliche Daten, Benutzerkonten und Rollen liegen in derselben Datenbankdomäne. Native SQL-Abfragen, Views, Trigger und Stored Procedures begrenzen einen schnellen Austausch der Datenbank oder des ORM-Frameworks.
Die Tomcat-Authentifizierung liest Passwortdaten direkt aus der Datenbank. Das Zielbild trennt die Identitätsverwaltung mit Keycloak von den fachlichen Benutzerdaten. Diese Umstellung benötigt eine kontrollierte Zuordnung bestehender Benutzer und Rollen.
Konsequenz für die Migration
Die Modernisierung erfolgt in getrennten, jeweils deploybaren Schritten:
- reproduzierbarer Maven-Build mit kompatiblem Tomcat-7-WAR,
- Entkopplung und Architekturvorbereitung,
- Java 21, Jakarta und Spring Boot,
- Keycloak und Spring Security,
- Flyway-basierter Datenbank-Lifecycle,
- Vue-3-Oberfläche,
- modernisierte Delivery- und Betriebsprozesse,
- Integration in Kubernetes.
Diese Reihenfolge begrenzt die Anzahl gleichzeitig veränderter Komponenten und erhält einen vergleichbaren Referenzstand.