Releasenotes 2026 OS.Softwarefactory

Version 5.3.0.20261103

• OSBP Framework:
  • Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header OSBP-Flyway-Migration: db/migration und legt die Skripte als <Persistence Unit>/<Hersteller>/V<Version>__<Beschreibung>.sql ab, z.B. monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: mysql (auch für MariaDB), postgresql, oracle, sqlserver, h2, derby. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie db/migration nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse BundleMigrations sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (-DFlyway.<Datenquelle>.DatabaseMigrationSourcePath) werden wie bisher mitgelesen. Die Migrationen laufen weiterhin nur mit -DFlyway.active=true; keine ausgelieferte Anwendung schaltet sie bisher ein Betroffene Komponenten: org.eclipse.osbp.persistence
  • Neu: HikariCP-Verbindungspool vor der Datenquelle des Treibers. Bisher öffnete jede Abfrage eine neue Verbindung zur Datenbank, etwa 3.000 je stündlichem Lauf des Zeitplaners auf einer ruhenden Kasse. Maximum ist database.connectionpool.max, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. -DPersistenceService.connectionPool=false schaltet den Pool ab; .minIdle, .maxLifetimeMinutes und .leakDetectionSeconds stellen ihn ein. Betroffene Komponenten: org.eclipse.osbp.persistence
  • Neu: Jeder Eintrag der Systemüberwachung enthält die Auslastung des Verbindungspools in Prozent und die Zahl der wartenden Threads. Wartende Threads markieren den Eintrag Memorycheck als Warnung. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base
  • Änderung: db/README.md beschreibt Aufbau, Versions- und Historienkonventionen sowie die Regeln für ein Migrationsskript (nie ein ausgeliefertes Skript ändern, sondern eine neue Version schreiben; jeden Datenbankzustand vertragen, weil das Skript vor dem Anlegen der Tabellen läuft; Objekte an ihrer Struktur statt an ihrem Namen finden). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base
  • Änderung: Die Tabelle „Flyway info“ im Log richtet ihre Spaltenbreiten nach dem Inhalt. Bisher schnitten feste Breiten Version und Beschreibung ab (2026.10.28.1 erschien als 2026.10.). Betroffene Komponenten: org.eclipse.osbp.persistence
  • Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, flyway_ und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): org.eclipse.osbp.system.monitoring.base wird zu flyway_oeos_monitoring_base, net.osbee.app.bdi.ex.model.entity zu flyway_noa_bdi_ex_model_entity. Versionen müssen daher nur innerhalb eines Bundles eindeutig sein; zwei Entwickler können in verschiedenen Bundles dieselbe Versionsnummer vergeben. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of <Bundle> were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle flyway_schema_history; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence
  • Fix: Das Grid fragt nach einem Wechsel des Inhalts nicht mehr für jede bekannte Zeile einzeln beim Container nach. Bei einem lazy ladenden Container war das je Zeile ein SELECT COUNT: Ein Lauf des Zeitplaners mit offener Perspektive machte 10.468 Abfragen, danach 787. Die Schlüssel von Zeilen, die der Client nicht mehr anzeigt, werden beim nächsten Zurücksetzen freigegeben. Betroffene Komponenten: org.eclipse.osbp.ecview.extension/org.eclipse.osbp.ecview.extension.grid.presentation
  • Fix: Eine Ansicht zeigt nach einer Folge von Änderungen immer den letzten Stand. Bisher wurden Aktualisierungen während des Zeichnens oder innerhalb der Ruhezeit (RefreshTimeout, Standard 300 ms) verworfen, sodass die letzte Änderung fehlen konnte. Jetzt werden sie zurückgestellt: Die Ansicht zeichnet einmal nach der letzten Anforderung, spätestens 5 Sekunden nach der ersten zurückgestellten. Gilt für alle Ansichten über AbstractHybridVaaclipseView (Tabellen, Diagramme, Berichte). Die Zahl der Abfragen sinkt dadurch nicht zwingend: gemessen am Überwachungsdiagramm 4 statt 3 bei einem Lauf des Zeitplaners, dafür mit dem letzten Stand. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api
  • Fix: Flyway lief bei jedem Start mit baseline(). Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – migrate() lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über baselineOnMigrate einmalig mit Version 0 versehen. Ebenso entfällt repair() bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (outOfOrder), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr. Der Lizenzschlüssel für die kommerzielle Flyway-Edition wird nicht mehr gelesen; die Open-Source-Edition genügt. Betroffene Komponenten: org.eclipse.osbp.persistence
  • Fix: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (EclipseLink/<Unit>#cacheTypeDefault, #cacheSizeDefault) aus der Konfiguration. Die Units werden parallel in einem Thread-Pool angelegt; das Lesen der Konfiguration holt DTO-Dienste und Mapper über Declarative Services, deren Sperre der Start-Thread während des gesamten Persistenzstarts hält. Jeder Pool-Thread wartete daher, bis DS nach 20 s aufgab. Die Werte werden nun vorher einmal auf dem Start-Thread gelesen, der die Sperre erneut nehmen darf; die Pool-Threads erhalten sie aus dem Zwischenspeicher der Konfiguration. Die Vorgabewerte (Soft, 1000) sind Konstanten, sodass beide Lesestellen dieselben verwenden. Betroffene Komponenten: org.eclipse.osbp.persistence
  • Fix: Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (MONITOR_SUB_CATEGORY.MSC_NAME, MONITOR_CATEGORY.MCA_NAME und DK, MONITOR_MAIN_CATEGORY.MMCA_NAME, MONITOR_COMPONENT.MCO_NAME). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter XRECHNUNG_UP und unter ZUGFERD_UP – scheiterte daher an einem doppelten Schlüssel, MonitoringService fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (V2026.10.28.1__drop_stale_monitor_unique_indexes.sql, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; MONITOR_COMPONENTI1 legt die Schemagenerierung danach in der Form des Modells (MCO_NAME, MCO_INSTALLATION) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts. Die PostgreSQL- und Oracle-Skripte sind ungetestet. Ohne Flyway lassen sich die Indizes auch von Hand entfernen (auf den lokalen Datenbanken shipment und pos geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base

• DSL:
  • Fix: Der Diagramm-Generator setzt den Zähler je Datenreihe zurück (ab 500 Zeilen passten Reihen und Beschriftung sonst nicht zusammen), Linien verschwinden beim Überfahren nicht mehr, der Tooltip nennt die Kategorie, und die Animation läuft nur noch beim ersten Zeichnen. Betroffene Komponenten: org.eclipse.osbp.xtext.chart
  • Änderung: Das Speicherdiagramm der Überwachung ist mit dem korrigierten Generator neu erzeugt. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring

• Build & Infrastruktur:
  • Fix: Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul flyway-mysql, das sich über META-INF/services registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment org.flywaydb.database.mysql 9.14.0.v20261028 an org.flywaydb.core ausgeliefert (das Manifest des Originals nennt sich selbst org.flywaydb.core und ist so nicht verwendbar) und mit dem Feature org.eclipse.osbp.dependencies.feature.flyway verteilt. Ohne das Fragment endet Flyway auf MariaDB mit „Unsupported Database: MySQL 5.5“ (so meldet der alte MySQL-Treiber eine MariaDB). PostgreSQL und Oracle sind weiterhin im Kern enthalten. Das per Maven gebaute Fragment ist noch nicht auf einer Installation geprüft; Build-Reihenfolge: dependencies-mbp, dependencies, persistence, system.configuration. Betroffene Komponenten: org.eclipse.osbp.dependencies-mbp/org.eclipse.osbp.dependencies.bundle.flyway.mysql, org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.flyway
  • Neu: HikariCP 4.0.3 wird als Feature mit ausgeliefert. Es ist wie Flyway aus den Quell-Features ausgenommen. Betroffene Komponenten: org.eclipse.osbp.dependencies/org.eclipse.osbp.dependencies.feature.hikaricp, org.eclipse.osbp.dependencies.p2, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.feature, org.eclipse.osbp.technologystack/org.eclipse.osbp.technologystack.target.feature, org.eclipse.osbp.persistence/org.eclipse.osbp.persistence.feature, org.eclipse.osbp.softwarefactory/org.eclipse.osbp.softwarefactory.runtime.feature

Version 5.3.0.20261029

• OSBP Framework:
  • Fix: org.eclipse.osbp.persistence: Wartezeit beim Start („Getting a lock required more than 20000 ms“). Jede Persistence Unit las beim Anlegen ihren EclipseLink-Cachetyp und ihre Cachegröße (EclipseLink/<Unit>#cacheTypeDefault, #cacheSizeDefault) aus der Konfiguration. Das führte zu einer gegenseitigen Blockierung der Initialisierung. Die Werte werden nun einmal auf dem Start-Thread gelesen, damit tritt die Sperre nicht mehr auf.
  • Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header OSBP-Flyway-Migration: db/migration und legt die Skripte als <Persistence Unit>/<Hersteller>/V<Version>__<Beschreibung>.sql ab, z.B. monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql. Ein Skript läuft auf der Datenquelle, für die seine Persistence Unit konfiguriert ist, und zwar vor dem Anlegen und Erweitern der Tabellen durch EclipseLink. Der Herstellerordner wird aus den JDBC-Metadaten bestimmt: mysql (auch für MariaDB), postgresql, oracle, sqlserver, h2, derby. Die neue Klasse BundleMigrations sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (-DFlyway.<Datenquelle>.DatabaseMigrationSourcePath) werden mitgelesen. Die Migrationen laufen nur mit -DFlyway.active=true;
  • org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, flyway_ und der symbolische Name, gekürzt wie ein Logger Klassennamen kürzt (führende Segmente auf ihren Anfangsbuchstaben, bis höchstens 30 Zeichen erreicht sind): org.eclipse.osbp.system.monitoring.base wird zu flyway_oeos_monitoring_base, net.osbee.app.bdi.ex.model.entity zu flyway_noa_bdi_ex_model_entity. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of <Bundle> were NOT applied“ protokolliert, die übrigen Bundles laufen weiter. Ergäben zwei Bundles denselben gekürzten Namen, werden beide mit einem Fehler abgewiesen, statt sich eine Historie zu teilen. Die Skripte des Dateisystemordners behalten Flyways Standardtabelle flyway_schema_history; eine Quelle ohne Skripte läuft gar nicht
  • Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit baseline(). Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – migrate() lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über baselineOnMigrate einmalig mit Version 0 versehen. Ebenso entfällt repair() bei jedem Start: Es schrieb die Historie auf ein nachträglich geändertes oder ersetztes Skript um, das dann nie lief; ein solches Skript scheitert nun an der Prüfsumme. Versionen dürfen außer der Reihe eintreffen (outOfOrder), ein entferntes, bereits gelaufenes Skript ist kein Fehler mehr.
  • Fix: org.eclipse.osbp.system.configuration (monitoring.base): Überwachungseinträge gingen auf älteren Datenbanken verloren. Datenbanken, die mit einem früheren Monitoring-Modell angelegt wurden, tragen noch eindeutige Indizes auf einem Namen allein (MONITOR_SUB_CATEGORY.MSC_NAME, MONITOR_CATEGORY.MCA_NAME und DK, MONITOR_MAIN_CATEGORY.MMCA_NAME, MONITOR_COMPONENT.MCO_NAME). Das Modell verlangt einen eindeutigen Namen nur unterhalb des jeweiligen Elternelements; die Schemagenerierung legt Indizes an, entfernt aber nie einen. Eine zweite Kategorie mit einer gleichnamigen Unterkategorie – etwa „COMPLETE“ unter XRECHNUNG_UP und unter ZUGFERD_UP – scheiterte daher an einem doppelten Schlüssel, MonitoringService fing den Fehler ab, und der Eintrag fehlte (auf einer BDI-Installation über 1.000 solcher Fehler an einem Tag, dazu „transactionRollback - no transactionhandler found“). Ebenso konnten sich zwei Installationen mit gemeinsamer Datenbank nicht beide als Komponente „Application“ anmelden. Die erste Flyway-Migration des Bundles (V2026.10.28.1__drop_stale_monitor_unique_indexes.sql, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; MONITOR_COMPONENTI1 legt die Schemagenerierung danach in der Form des Modells (MCO_NAME, MCO_INSTALLATION) neu an. Da die Indizes nicht mehr im Modell stehen, hängen ihre Namen vom Generator ab, der die Datenbank angelegt hat; die Skripte finden sie daher an ihrer Struktur (eindeutig, kein Primärschlüssel, genau eine dieser Spalten). Auf einer neuen oder bereits bereinigten Datenbank ändern sie nichts.

• Allgemein:
  • Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle org.eclipse.ecf.osgi.services.remoteserviceadmin.console (Konsolenbefehle rsa …) sollte nicht automatisch starten. Seine Komponente RSACommand benötigt den RemoteServiceAdmin; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (-Dequinox.scr.waitTimeOnBlock, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf autoStart="false" gesetzt; POS startet es nicht. Zusammen mit der Korrektur oben startet BDI in der IDE ohne Sperrmeldungen (67 s statt 74–101 s). Es verbleibt die Warnung „Enabling components of bundle org.eclipse.osbp.xtext.builder.metadata.services did not complete in 30000 ms“: Das ist das Laden der DSL-Modelle (rund 35 s) auf dem DS-Thread, keine Sperre

• Build & Infrastruktur:
  • Flyway Integration: org.eclipse.osbp.dependencies-mbp, org.eclipse.osbp.dependencies - Flyway 9 enthält die Unterstützung für MySQL und MariaDB nicht mehr im Kern, sondern im Modul flyway-mysql, das sich über META-INF/services registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment org.flywaydb.database.mysql 9.14.0.v20261028 an org.flywaydb.core ausgeliefert (das Manifest des Originals nennt sich selbst org.flywaydb.core und ist so nicht verwendbar) und mit dem Feature org.eclipse.osbp.dependencies.feature.flyway verteilt.

Version 5.3.0.20261012

• OSBP Framework:
  • org.eclipse.osbp.dsl (Entity,DTO):
    • Fix: Speicherwachstum durch DTOs behoben (1) – AbstractOppositeDtoList und MappingContext deklarieren kein finalize() mehr. Jede OppositeDtoList und OppositeContainmentDtoList war dadurch finalisierbar, überlebte die Garbage Collection, die sie als unerreichbar erkannt hatte, und hielt bis zur Abarbeitung durch den einzelnen Finalizer-Thread ihren gesamten Objektgraphen am Leben (DTOs, Entitäten, Persistenzkontexte). In einem Kundenabzug waren von 7,56 Mio. Finalizer-Einträgen 7,51 Mio. solche Listen. Die Listener, die der Finalizer abmelden sollte, werden bereits in clear(), remove() und resolve() abgemeldet
    • Fix: Speicherwachstum durch DTOs behoben (2) – ein DTO hält für das spätere Nachladen einer Lazy-Referenz nicht mehr die abgelöste Entität fest, sondern nur noch deren Klasse und ID (neue Klasse DetachedEntityRef in org.eclipse.osbp.dsl.dto.lib). Die Entität hielt über ihre Lazy-Beziehungen den gesamten Persistenzkontext (RepeatableWriteUnitOfWork samt aller darin geklonten Entitäten), obwohl LazyManyToOneResolver nur Klasse und ID benötigt. Gemessen an einer Kasse: rund 42 festgehaltene Persistenzkontexte je Verkauf vorher, praktisch keiner danach. Die ID wird erst am Ende des Mappings übernommen, weil der generierte Mapper initialize(entity) vor setId aufruft und eine neue Entität bis dahin die zufällige ID ihres Konstruktors trägt; liefert die Datenbank die ID erst später, bleibt es beim bisherigen Verhalten. Der Generator (DtoTypesBuilder) erzeugt den neuen Aufruf; wirksam wird die Änderung erst mit neu generierten DTOs. Nicht neu generierte DTOs laufen unverändert weiter; neu generierte DTOs setzen ein dto.lib ab dem 07.10.2026 voraus
    • LazyManyToOneResolver meldet nun, welche Zeile er nicht nachladen konnte. Liefert em.find kein Ergebnis, wird ein Fehler mit Entitätsklasse, ID, Eigenschaft und DTO-Klasse protokolliert und eine IllegalStateException geworfen. Bisher erschien an dieser Stelle nur eine NullPointerException ohne Hinweis auf die Ursache
    • Fix: AbstractDTOService.closeEntityManager() fordert eine offene Transaktion nicht mehr nach jedem Lesezugriff zur Freigabe auf. Das Verhalten ist unverändert, die Warnung dispose() refused erscheint aber nur noch, wenn tatsächlich jemand eine offene Transaktion abbauen will (zuvor rund zwei Meldungen je Verkauf und etwa 175 je Kassenabschluss)
    • Fix: Mit -DsendTransactionEventAsync=true wartete TransactionHandler.dispose() nach jedem Commit mindestens 800 ms, zuzüglich weiterer 800 ms je Durchlauf mit nicht leerer Ereigniswarteschlange – während SessionManager die Sperre aller Transaktions-Handler hielt. An einer Kasse waren das mehrere Sekunden je Bon. dispose() übergibt den Entity Manager nun dem Ereignis-Thread und kehrt sofort zurück; der Thread schließt ihn als letzten Schritt, sobald seine Warteschlange leer ist. Ein Ereignis, das sich nicht versenden lässt, beendet den Thread nicht mehr. Ohne den Schalter ändert sich nicht*s
  • Fix: MetadataBuilder macht beim ersten Scan zunächst alle gestarteten Bundles mit dem Header OSBP-RuntimeBuilder-BundleSpace oder Factory-Model im Bundle-Space bekannt und sucht erst danach nach Modellen. Bisher wurde ein Bundle erst beim Erreichen aufgenommen, während ein Participant ein Modell sofort laden kann: Ein ECView aus org.eclipse.osbp.system.configuration nennt ein DTO aus org.eclipse.osbp.system.configuration.base mit der höheren Bundle-ID, die Klasse wurde also je nach Reihenfolge beim Start nicht gefunden. In diesem Fall scheiterte activate(), der DSL-Metadatendienst und damit der Persistenzdienst starteten nie, und die Anwendung blieb auf der Startseite stehen. Eine fehlgeschlagene Aktivierung wird nun zusätzlich als Fehler in das Anwendungslog geschrieben
  • Fix: org.eclipse.osbp.dsl, org.eclipse.osbp.runtime: Vier Fehler in der sitzungsbezogenen Transaktionsverwaltung behoben. (a) SessionManager.removeSession() gab den Transaktions-Handler unter einem Schlüssel frei, der nie passen konnte (ISession hat kein toString()), das Sicherheitsnetz griff also nie. (b) disposeTransactionHandler entfernte den Eintrag auch dann, wenn die Transaktion noch offen war – der Entity Manager wurde aufgegeben und der Thread, der die Transaktion noch abschließen musste, fand seinen Handler nicht mehr. ITransactionHandler erhält dafür isDisposable() als Default-Methode. (c) Die Freigabe nach transactionBegin/Commit/Rollback steht nun in einem finally; ein Error, insbesondere ein OutOfMemoryError, ließ den Handler bisher mit Entity Manager in einer statischen Map zurück. (d) txnIsOpen wird auch bei einem fehlgeschlagenen Commit oder Rollback zurückgesetzt
  • org.eclipse.osbp.persistence:
    • Der Startstatus nennt nun den Dienst, auf den der Persistenzdienst noch wartet. Die neue Komponente PersistenceStartupStatus hat keine Pflichtreferenz, ist daher von Beginn an aktiv und setzt den Status auf „persistence service is waiting for the DSL metadata service“ (bzw. „the Mondrian manager“), bis diese gebunden sind. Bisher blieb es unabhängig vom Grund bei „persistenceservice not started yet“, und die wartenden Dienste protokollierten nichts
    • Beim Einrichten einer Persistence Unit wird jede verwaltete Klasse gemeldet, die nicht statisch gewebt ist, obwohl eine ihrer Oberklassen es ist – in einer ERROR-Zeile mit dem Hinweis, das Projekt vollständig neu zu bauen. Eine solche Klasse wird von EclipseLink instanziiert, aber nie befüllt: Der Dialog bleibt leer, und die nächste Aktualisierung scheitert mit „mapped to a primary key column ... Updates are not allowed“
  • org.eclipse.osbp.ecview.extension: Fix: Das Grid vergisst die Zeilenschlüssel von Einträgen, die den Container als Ganzes verlassen haben. Vaadin gibt die Schlüssel nur über das clientseitige dropRows frei; nach einem allgemeinen ItemSetChange, wie ihn removeAllItems() und addAll() auslösen, blieben sie im KeyMapper stehen und hielten jede jemals angezeigte Zeile samt ihrem DTO-Graphen. GridPresentation.CustomGrid merkt sich die vergebenen Schlüssel und entfernt die nicht mehr enthaltenen
  • org.osbee.datainterchange: Fix: FreeMarkers gemeinsam genutzte InvalidReferenceException hält nicht mehr den ersten Exportlauf fest. Die statische Instanz übernahm die zum Zeitpunkt ihres Entstehens aktive Umgebung und damit das gesamte Datenmodell des ersten Exports für die Lebensdauer des Prozesses. Der Activator lädt die Klasse nun einmal außerhalb eines Template-Laufs
  • org.eclipse.osbp.display: Fix: Das Display-Servlet wird nicht mehr auf dem Thread registriert, der die Bundles startet. Die Registrierung veröffentlicht einen Dienst, und Declarative Services verarbeitet dieses Ereignis auf dem veröffentlichenden Thread; dort wartete der Start aller nachfolgenden Bundles, in einem Fall über 50 Sekunden („Getting a lock required more than 50000 ms“). Die Registrierung läuft nun auf einem eigenen Thread
  • org.eclipse.osbp.runtime, org.eclipse.osbp.blob, org.eclipse.osbp.autowireHelper, org.eclipse.osbp.ecview.extension, org.eclipse.osbp.ecview.addons, org.eclipse.osbp.infogrid.model: Neue Eigenschaft barcode für String-Attribute. Ein Attribut mit key="barcode" value="QRCode-128" wird schreibgeschützt als Barcode-Bild angezeigt, das aus seinem Klartextwert erzeugt wird – im Dialog über BlobComponent und BlobUploadComponent (letztere dann ohne Schaltflächen) und in Grid-Spalten über den Blob-Bildkonverter
  • org.eclipse.osbp.authentication, org.eclipse.osbp.system.configuration, org.eclipse.osbp.blob: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (DetachedEntityRef)

• DSL:
  • org.eclipse.osbp.xtext.table, org.eclipse.osbp.xtext.table.common: Für Attribute mit der Eigenschaft barcode wird ein Barcode-Lookup generiert; eine String-Zelle wird als Barcode-Bild angezeigt, wenn das Lookup einen Barcode-Typ trägt

• POS Framework:
  • net.osbee.pos.tse: Aufrufer können die BSI-Zertifizierungs-ID der TSE abfragen. Die SE-API bietet getCertificationId in beiden API-Versionen, keiner der beiden Adapter reichte den Aufruf bisher durch
  • net.osbee.pos.tse, net.osbee.pos.rksv: DTOs neu generiert; sie halten nur noch Klasse und ID ihrer Entität (DetachedEntityRef)

Version 5.3.0.20261006

• OSBP Framework (Allgemein):
  • Einführung der http://<host>:<port>/restartService Seite. Damit können entweder Sessions gekillt oder der Service der Anwendung neu gestartet werden.
  • Bei Nichterreichbarkeit der Datenbank wird die Anwendung beendet und der Fehlerstatus auf der Statusseite angezeigt.
  • Das eingebettete shiro-all-1.2.3.jar wurde durch shiro-core und shiro-web in Version 1.13.0 ersetzt. Damit sind CVE-2016-4437 (Remote Code Execution über das RememberMe-Cookie mit festem Schlüssel) und CVE-2019-12422 geschlossen. encoder-1.2.3.jar kommt hinzu, weil shiro-web 1.13 org.owasp.encoder zwingend importiert.
  • Anmeldung:
    • Fix: LDAPRealm löst den Anmeldenamen vor jeder Abfrage in einen Distinguished Name auf. Active Directory akzeptiert für den Bind auch einen User Principal Name, beantwortet Abfragen damit aber mit LDAP-Fehler 34 (invalidDNSyntax), sodass ein userDnTemplate von {0} zwar anmeldete, dann aber an den Attributen scheiterte. resolveUserDn sucht nun über userPrincipalName, sAMAccountName oder mail; die Suchbasis stammt aus dem RootDSE. Bestehende Vorlagen der Form cn={0},ou=... verhalten sich unverändert. Zugleich behoben: eine StringIndexOutOfBoundsException im E-Mail-Zweig und das Einsetzen des Benutzernamens in den Suchfilter per Verkettung (jetzt als {0}, von JNDI maskiert)
    • Fix: LDAPRealm.getUserDn maskierte nur das Komma. escapeDnValue deckt nun alle Zeichen nach RFC 4514 Abschnitt 2.4 ab, sodass ein Benutzername die Bedeutung des DN nicht mehr verändern kann
    • Die Funktionalität „Angemeldet bleiben“ arbeitet nun mit einem signierten Token statt mit verschlüsselten Zugangsdaten. Das Cookie ist eine mit HMAC-SHA256 signierte Aussage über Benutzer, Mandant, Geltungsbereich, Ablaufdatum und Version und enthält keine Zugangsdaten. Es ist zustandslos, sodass beliebig viele Geräte und Browser gleichzeitig eines halten können.
    • Das „Angemeldet bleiben“-Cookie gilt je Anwendungsinstanz und Browser. Der Cookie-Name trägt einen Kurzhash über Schema, Host, Port, erstes Pfadsegment und Portal-ID, sodass zwei Anwendungen auf demselben Host nicht mehr das Cookie der jeweils anderen lesen. Die selbstgebaute Verschlüsselung entfällt vollständig. Das Cookie wird mit expliziter Lebensdauer, SameSite=Lax und unter https mit Secure geschrieben. Die Anmeldung aus einem Cookie wartet fünf Sekunden mit einem Hinweis auf der Anmeldemaske und lässt sich in dieser Zeit abbrechen; ein entferntes Häkchen löscht das Cookie nun in jedem Fall. Die Betrugsmeldung samt Kontosperre bei nicht passendem Cookie entfällt
    • Fix: Kennwörter erscheinen nicht mehr im Log – weder bei der Anmeldung in AuthenticationProvider.check() (bisher im Klartext auf DEBUG) noch beim Zurücksetzen, wo der Nachrichtentext mit dem neuen Kennwort dreimal geschrieben wurde
    • Die Anzeige des neuen Kennworts auf der Anmeldemaske, wenn keine E-Mail versendet werden kann, ist nun eine konfigurierte Betriebsart: Userinterface/showResetPasswordOnScreen, standardmäßig aus, mit Protokollierung auf WARN. Installationen ohne Mailserver müssen den Parameter einmalig setzen
    • Fix: doResetPassword hebt weder eine Sperre noch die Deaktivierung eines Kontos auf und setzt den Fehlversuchszähler nicht mehr zurück. Das Zurücksetzen kann jeder auslösen, der einen Benutzernamen eingibt; aufgehoben werden Sperre und Deaktivierung nur noch durch einen Administrator über doUnlock
  • System Configuration:
    • Parameter RememberMeSecret in IConfigurationService ergänzt (GLOBAL_PARAMETERS/RememberMeSecret). Der Schlüssel wird je Installation bei der ersten Benutzung der "RememberMe" Funktionalität einmal aus gezogen und von allen Anmeldungen geteilt; das Löschen des Eintrags macht alle „Angemeldet bleiben“-Cookies auf einmal ungültig.
    • Fix: Die Einstellungen füllten sich mit Platzhaltern „not set“. ConfigurationService.getConfigurationString speicherte bei leerem Vorgabewert den Platzhalter und lieferte ihn als leere Zeichenkette zurück, sodass addConfiguration stets eine weitere Zeile anhängte. addConfiguration entfernt nun die Platzhalterzeilen des Schlüssels vor dem Schreiben, und ein gespeicherter Platzhalter gilt als „kein Wert“. deleteConfigurations setzt zusätzlich den Cache zurück; gelöschte Einträge kamen bisher beim nächsten Lesen wieder

• Build & Infrastruktur:
  • Fix: org.eclipse.osbp.dependencies-mbp: Das Bundle org.eclipse.osbp.dependencies.bundle.activemq.all.osgi enthält kein Log4j und kein eingebettetes slf4j mehr. activemq-all brachte eine vollständige Kopie von Apache Log4j 1.2.17 mit (359 Klassen, darunter JDBCAppender, JMSAppender, JMSSink und chainsaw – betroffen von CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 und CVE-2022-23307) sowie slf4j-api 1.7.13 und slf4j-log4j12. Include-Resource bindet das Hersteller-Jar nun ohne org.apache.log4j, org.slf4j, deren Maven-Koordinaten, die log4j.properties und Springs Log4jConfigurer ein. ActiveMQ bezieht slf4j stattdessen aus dem Produkt (org.slf4j.api 1.7.36)

• UI & Themes:
  • Neue Dienststeuerungsseite unter /restartService.
    • Ein Bediener kann darüber – autorisiert durch eine reguläre Anwendungsanmeldung – hängende Sitzungen beenden oder den Dienst neu starten, ohne Zugriff auf den Serverrechner zu benötigen. Drei Stufen: Sitzungen des aufrufenden Arbeitsplatzes, alle Sitzungen, Neustart. Die Seite ist am Root-HTTP-Service registriert und bleibt damit erreichbar, wenn der Anwendungskontext selbst gestört ist; Markup, Stil, Skript und Texte (deutsch, englisch, französisch) sind deshalb in der Seite enthalten. Sitzungen werden über das Invalidieren der HTTP-Sitzung beendet. Der Neustart läuft über die Befehlswarteschlange der Anwendung; die Seite fragt anschließend die Anwendung ab und führt den Bediener über die Unterbrechung hinweg
    • Alle Aktionen der Dienststeuerungsseite werden im MonitoringService unter denselben Koordinaten wie die Anmeldemaske protokolliert (fehlgeschlagene Anmeldung und Neustart als WARNING, gesperrtes Konto als ERROR, beendete Sitzungen als INFO). Eine abgelehnte Anmeldung sperrt das Formular für die Dauer der Wartezeit mit Countdown; der Zähler ist derselbe wie an der Anmeldemaske, sodass sich Fehlversuche auf beiden Wegen zur Kontosperre summieren

Version 5.3.0.20260907

• OSBP Framework (Allgemein):
  • Überarbeitung der Codebasis zur Entfernung veralteter und nicht benötigter Bundles
  • Überarbeitung des Loginvorgangs / der Cookiespeicherung bei "remember me". Es werden keine kritischen Daten mehr im Cookie gespeichert.
  • Verbesserung der Übersetzungen
  • Anpassungen für frz. Fiskalanforderungen

Version 5.3.0.20260707

• OSBP Framework (Allgemein):
  • Laden der Übersetzungen in die interne Tabelle beim Systemstart deutlich beschleunigt. Dadurch verbessertes Startverhalten der Anwendungen.
  • Verbesserungen bei der frz. Tastaturunterstützung
  • Verbesserungen der Übersetzungen

Version 5.3.0.20260618

• OSBP Framework (Allgemein):
  • Blockieren durch das Laden von Diensten während des Starts vermieden, dadurch schnellerer Anwendungsstart. Anderes Verhalten beim Start an der Benutzeroberfläche.
  • Französische Tastaturunterstützung (AZERTY) im Keymapper der Statemachine ergänzt
  • Login bezieht Build-Version und Hersteller nun aus den BundleUtilities (einheitliche Quelle)
  • Neue gemeinsame Hilfsmethoden getBuildVersion()/getVendor() in BundleUtilities zur Ermittlung der Build-Identität
  • MonitoringService setzt die Zeitstempel von lastError und lastWarning nicht mehr zurück
  • Fix: NPE in org.eclipse.osbp.xtext.dialog.AutowireUiFactory behoben
  • Version von 5.2.0 auf 5.3.0 angehoben

• UI & Themes:
  • Neues Icon action-reverify (16px/32px) für die NF525-Schaltfläche zur erneuten Archivintegritätsprüfung
  • Neues Icon action-refresh.png ergänzt
  • Grid – horizontale Bildlaufleiste wiederhergestellt
  • Grid - Flex-Layout für Kassen-/POS-Grids wiederhergestellt (kollabierte Spalten behoben)
  • französische Übersetzungen überarbeitet

• Grammatiken/Generierung:
  • org.eclipse.osbp.dsl: Benutzerdefinierte @PreRemove-Hooks werden in der generierten preRemove()-Methode zusammengeführt
  • org.eclipse.osbp.xtext.i18n: i18n-Generator erzeugt nun das byte-genaue Eclipse-Babel-Format

• POS Framework für franz. Fiskalanforderungen eingeführt

Version 5.2.0.20260410

• POS Framework:
  • Performanceverbesserung beim Kassieren
  • Multi-Protokoll Unterstützung für Paymentterminal
    • frz. Protokolle "Concert", "Protocol E"
    • "Mock" für Tests
    • Statemachine DSL erweitert: protocol Parameter für Paymentterminal
    • "Shared Payment Terminal"
      • locking im PaymentTerminalService implementiert
      • pro Terminal über ConfigService einstellbar

Version 5.2.0.20260402

Die Version verbessert das Startverhalten einer Anwendung und bringt mehr Informationen über den Status des Starts auf den Bildschirm

• OSBP Framework:
  • Anzeige des Persistenzservice-Status auf dem Login-Bildschirm
  • Information über den Persistenzservice auf der Fehlerseite hinzugefügt
  • Beim Start wird nun überall auf den Persistenzservice statt nur auf den ConfigurationService gewartet

• BPM:
  • Fix: net.osbee.bpm: Deadlock beim Anwendungsstart behoben

• POS Framework:
  • Fix: net.osbee.pos.epay: Deadlock beim Anwendungsstart behoben

Version 5.2.0.20260305

Report Anzeige

Diese Version konzentriert sich auf Stabilitätsverbesserungen für das Report-Rendering-System, insbesondere auf die Behebung von Race Conditions und Anzeigeproblemen, die bei schnellen Benutzerinteraktionen auftraten.

• Race Condition beim Report-Rendering
  • Behoben: Schnelles Auswählen/Abwählen führte dazu, dass Reports mit ungültigen oder fehlenden Filtern gerendert wurden
    • Reports verarbeiten nun korrekt wenn Benutzer schnell Elemente auswählen und wieder abwählen
    • Filteränderungen werden blockiert, während ein Render-Vorgang läuft
    • Ausstehende Filteränderungen werden nachverfolgt und nach Abschluss des Renderings erneut ausgewertet
    • Reports mit selectById werden nun korrekt ausgeblendet, wenn nichts ausgewählt ist

• PDF-Anzeigeskalierungsproblem
  • Behoben: PDF-Skalierungsprobleme durch Neuerstellung des BrowserFrames bei jedem Rendering

Anmeldebildschirm

Der Anmeldebildschirm zeigt nun während der Initialisierung des Persistence-Services einen Statustext an.

• Lauftext-Anzeige (Marquee) mit dem aktuellen Status des Persistence-Services
• Deaktivierung aller Anmeldesteuerelemente während der Wartezeit

Start der Anwendung

• Blockierungen der Initialisierungsvorgänge durch Warten auf Serviceregistrierung während des Anwendungsstarts reduziert.
  Dadurch verändert sich das Startverhalten, insbesondere die Reihenfolge der Anwendung. Insgesamt schnelleres Laden der Bundles.