Technologische Projekte

WildFly-Liquibase modernisiert

Das öffentlich einsehbare WildFly-Liquibase-Subsystem wurde auf modernere WildFly-, Java- und Liquibase-Versionen gehoben. Reparierte Ressourcenauflösung und Tests sorgen dafür, dass Datenbankänderungen auch in modernen Serverpaketen zuverlässig gefunden und vor dem Anwendungsstart ausgeführt werden.

Unternehmensnutzen: Datenbankschema und Anwendung bleiben gemeinsam versionierbar, ohne Liquibase in jede Anwendung einzubauen.

Flyway-Migrationen in WildFly automatisieren

Das öffentliche WildFly-Flyway-Subsystem startet Migrationen beim Deployment, ohne die Migrationslogik in jede Anwendung einzubauen. Zentrale Vorgaben, anwendungsspezifische Einstellungen und sichere Standardwerte lassen sich über dieselbe Server-Erweiterung verwalten.

Unternehmensnutzen: Datenbank und Anwendung werden in der richtigen Reihenfolge aktualisiert, während Betriebsteams die Kontrolle über Validierung und Konfiguration behalten.

Mandantenfähige Datenquellen deklarativ bereitstellen

Ein WildFly-Subsystem erzeugt aus einer gemeinsamen Vorlage beim Deployment für jeden Mandanten eine eigene, isolierte Datenquelle. Laufzeitwerte, Zugangsdaten und Poolgrößen kommen aus der Betriebsumgebung; nachträgliche Konfigurationsskripte entfallen.

Unternehmensnutzen: Viele Mandanten können dieselbe Plattform wirtschaftlich nutzen, ohne bei Trennung, Reproduzierbarkeit oder Betriebssicherheit Abstriche zu machen.

Umgebungsvariablen für bestehende Deployments nutzbar machen

Eine WildFly-Erweiterung überführt ausgewählte Umgebungsvariablen beim Serverstart in System Properties. Damit können auch bestehende Deployment-Deskriptoren containerabhängige Werte verwenden; Validierung, Maskierung sensibler Angaben und Fail-fast-Prüfungen sichern den Start ab.

Unternehmensnutzen: Gewachsene Java-Enterprise-Anwendungen werden containerfähig, ohne ihre bewährten Konfigurationsdateien umfassend umzubauen.

Buildpack für WildFly und JBoss EAP

Aus WAR, EAR oder JAR entsteht ohne projektspezifisches Dockerfile ein passendes Container-Image. Der Build erkennt benötigte Serverfunktionen, provisioniert einen möglichst kleinen WildFly und berücksichtigt interne Maven-Repositories, Zertifikate, Service-Bindings, Gesundheitsprüfungen und unveränderliche Container.

Unternehmensnutzen: Teams erhalten einen einheitlichen, wiederholbaren Weg vom Java-Artefakt zum betreibbaren Image.

EJB automatisch nach Spring übertragen

Die öffentliche OpenRewrite Migration Suite überführt typische EJB-, JNDI-, Transaktions-, REST-, Messaging- und Batch-Muster in eine Spring-Boot-Struktur. Eindeutige Fälle werden geändert; Stellen ohne sichere automatische Entscheidung werden markiert.

Unternehmensnutzen: Große Modernisierungen werden wiederholbar, prüfbar und deutlich weniger von manueller Fleißarbeit abhängig.

Stille Konfigurationsverluste verhindert

Ein Fehler im WildFly Maven Plugin ließ bestimmte Galleon-Konfigurationen trotz erfolgreichem Build verschwinden. Ein öffentlicher minimaler Reproduzierer machte das Verhalten messbar; der Patch im Plugin-Fork erhält die vollständige Konfiguration und lässt ungültige Angaben sichtbar fehlschlagen.

Unternehmensnutzen: Ein grüner Build steht wieder für den tatsächlich vorgesehenen Server – nicht nur für ein erfolgreich beendetes Werkzeug.

SOAP-Dienste automatisch veröffentlichen

Eine Erweiterung für Apache CXF erkennt vorhandene JAX-WS-Dienste in Spring-Boot-Anwendungen und veröffentlicht sie mit einheitlichen Adressen und klarer Diagnose. Prüfungen verhindern doppelte Endpunkte, ungeeignete Proxys und unvollständige Konfiguration.

Unternehmensnutzen: Gewachsene SOAP-Schnittstellen lassen sich mit weniger Spezialkonfiguration in moderne Anwendungen übernehmen.

OpenRewrite präziser gemacht

Öffentlich einsehbare Beiträge zum OpenRewrite-Kern korrigieren die XPath-Auswertung bei unterschiedlich formatierten Bedingungen und erweitern Tests für Maven-Abhängigkeitsverwaltung. Die Änderungen wurden im öffentlichen Projekt nachvollziehbar geprüft und übernommen.

Unternehmensnutzen: Automatische Refactorings funktionieren zuverlässiger auch bei realen, nicht einheitlich formatierten Projektdateien.

Apache Jackrabbit JTA-kompatibel gemacht

Ein öffentlicher Patch für Apache Jackrabbit verhindert direkte JDBC-Transaktionssteuerung, wenn ein Java-Application-Server die aktive JTA-Transaktion bereits verwaltet. Der Fehler wurde reproduziert, getestet und als Beitrag eingereicht.

Unternehmensnutzen: Dokumentenablage und Geschäftslogik können dieselbe verwaltete Transaktion nutzen, ohne widersprüchliche Commit- oder Rollback-Aufrufe.