Releasenotes 2026 OS.Softwarefactory - Revision history

Mollik at 10:59, 9 November 2026

2026-11-09T10:59:24Z

Mollik at 09:44, 9 November 2026

2026-11-09T09:44:06Z

Mollik at 13:50, 6 November 2026

2026-11-06T13:50:22Z

Mollik at 12:11, 4 November 2026

2026-11-04T12:11:55Z

Mollik at 12:05, 4 November 2026

2026-11-04T12:05:53Z

Mollik at 10:46, 4 November 2026

2026-11-04T10:46:39Z

Mollik: /* Version 5.3.0.20261029 */

2026-10-29T10:41:17Z

‎Version 5.3.0.20261029

Mollik: /* Version 5.3.0.20261029 */

2026-10-29T10:39:59Z

‎Version 5.3.0.20261029

Mollik: /* Version 5.3.0.20261029 */

2026-10-29T10:39:31Z

‎Version 5.3.0.20261029

Mollik at 10:38, 29 October 2026

2026-10-29T10:38:35Z

@@ Line 6: / Line 6: @@
 * OSBP Framework:
 ** Fix: QR-Codes in Bildfeldern werden jetzt angezeigt, z. B. auf der Kundenanzeige. Bisher blieb das Feld leer. Andere Barcodes und Bilder werden wie bisher angezeigt. Betroffene Komponenten: org.eclipse.osbp.runtime.web/org.eclipse.osbp.runtime.web.ecview.presentation.vaadin
 ** Änderung: Die Anwendung ist beim Start schneller bereit. Die Datenbankanbindung wartet nicht mehr, bis alle Modelle vollständig eingelesen sind, sondern startet, sobald die Modelle gefunden sind; das Einlesen läuft parallel weiter. In der Entwicklungsumgebung war die Anwendung dadurch nach etwa 61 statt 111 Sekunden bereit. Betroffene Komponenten: org.eclipse.osbp.ui.api, org.eclipse.osbp.dsl/org.eclipse.osbp.xtext.builder.metadata.services, org.eclipse.osbp.dsl.metadata.service, org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service

← Older revision		Revision as of 09:44, 9 November 2026
Line 2:		Line 2:

	== [[Releasenotes \| --> zurück zu Releasenotes ]] ==		== [[Releasenotes \| --> zurück zu Releasenotes ]] ==
		+
		+	== Version 5.3.0.20261109 ==
		+
		+	* OSBP Framework:
		+	** Fix: QR-Codes in Bildfeldern werden jetzt angezeigt, z. B. auf der Kundenanzeige. Bisher blieb das Feld leer. Andere Barcodes und Bilder werden wie bisher angezeigt. Betroffene Komponenten: org.eclipse.osbp.runtime.web/org.eclipse.osbp.runtime.web.ecview.presentation.vaadin
		+	** Änderung: Die Anwendung ist beim Start schneller bereit. Die Datenbankanbindung wartet nicht mehr, bis alle Modelle vollständig eingelesen sind, sondern startet, sobald die Modelle gefunden sind; das Einlesen läuft parallel weiter. In der Entwicklungsumgebung war die Anwendung dadurch nach etwa 61 statt 111 Sekunden bereit. Betroffene Komponenten: org.eclipse.osbp.ui.api, org.eclipse.osbp.dsl/org.eclipse.osbp.xtext.builder.metadata.services, org.eclipse.osbp.dsl.metadata.service, org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service
		+
		+	* DSL:
		+	** Änderung: Auch die Editoren für Datenschnittstellen (Datainterchange) und Signale arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.datainterchange/org.eclipse.osbp.xtext.datainterchange.ui, org.eclipse.osbp.xtext.signal/org.eclipse.osbp.xtext.signal.ui

	== Version 5.3.0.20261106 ==		== Version 5.3.0.20261106 ==

← Older revision		Revision as of 13:50, 6 November 2026
Line 2:		Line 2:

	== [[Releasenotes \| --> zurück zu Releasenotes ]] ==		== [[Releasenotes \| --> zurück zu Releasenotes ]] ==
		+
		+	== Version 5.3.0.20261106 ==
		+
		+	* OSBP Framework:
		+	** Neu: Die Seite <code>/showLog</code> zeigt im laufenden Betrieb das Ende des Protokolls (die letzten 500 Zeilen), mit Textfilter, Aktualisieren und Herunterladen der aktuellen Datei. Anmelden können sich nur Benutzer mit der Superuser-Eigenschaft, mit derselben Sperre nach Fehlversuchen wie bei der normalen Anmeldung. Jeder Zugriff wird im Monitoring festgehalten. Die Seite ist standardmäßig ausgeschaltet und wird in der Systemkonfiguration mit <code>GLOBAL_PARAMETERS / showLog</code> eingeschaltet. Da dabei ein Passwort übertragen wird, sollte die Anwendung über HTTPS erreichbar sein. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app, org.eclipse.osbp.ui.api, org.eclipse.osbp.authentication, org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager
		+	** Neu: Auf der Seite <code>/showLog</code> lässt sich die Schrift des Protokolls mit den Schaltflächen A− und A+ verkleinern und vergrößern. Die gewählte Größe bleibt beim Aktualisieren und Filtern erhalten, bis zur nächsten Anmeldung. Betroffene Komponenten: org.eclipse.osbp.vaaclipse.addons/org.eclipse.osbp.vaaclipse.addons.app
		+	** Änderung: Wird eine falsche Adresse aufgerufen, zeigt die Hinweisseite jetzt alle Einstiegspunkte in einer Tabelle: Anwendung, Kundenanzeige (Display), Protokollseite und Dienststeuerung. Die automatische Weiterleitung zur Anwendung erfolgt nach 5 statt 3 Sekunden. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager
		+	** Fix: Änderungen in der Systemkonfiguration wirken nach dem Speichern im Dialog wieder sofort. Seit Juni 2025 wurden Aufgaben, die nach dem Speichern im Hintergrund laufen sollen, nicht mehr ausgeführt; Konfigurationsänderungen wurden dadurch erst nach bis zu einer Stunde wirksam, und auch die Nachbearbeitung nach dem Speichern mancher Daten (z. B. für die Suche) unterblieb. Betroffene Komponenten: org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.postpersistservice
		+	** Fix: Monitoring-Einträge mit dem Status „Info“ werden korrekt gespeichert. Bisher wurden sie als „Unbekannt“ abgelegt, und im Protokoll erschien ein Fehler. Nach dem Update wird die Datenbankstruktur des Monitorings einmalig geprüft. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base
		+
		+	* DSL:
		+	** Änderung: Die Vorschläge im Editor der Funktionsbibliothek (Strg+Leertaste) erscheinen jetzt auch in großen Dateien ohne spürbare Wartezeit. Bisher wurde bei jedem Aufruf die ganze Datei neu gelesen, was in großen Dateien mehrere Sekunden dauern konnte. Die Gliederung (Outline) wird erst aktualisiert, wenn zwei Sekunden lang nicht getippt wurde, und bremst das Tippen dadurch nicht mehr. Auch das Einfärben und das Ein- und Ausklappen von Abschnitten werden nicht mehr bei jedem Aufruf der Vorschläge für die ganze Datei neu berechnet, sondern nur nach einer Änderung. Ist in der Gliederung „Mit Editor verknüpfen“ eingeschaltet, wartet der Editor nach größeren Änderungen nicht mehr, bis die Datei vollständig geprüft ist. Betroffene Komponenten: org.eclipse.osbp.xtext.functionlibrary/org.eclipse.osbp.xtext.functionlibrarydsl.ui
		+	** Änderung: Die Editoren für Entitäten, DTOs, Statemachines und Datamarts arbeiten jetzt wie der Editor der Funktionsbibliothek: Die Vorschläge (Strg+Leertaste) erscheinen auch in großen Dateien ohne spürbare Wartezeit, Gliederung, Einfärben und Ein- und Ausklappen bremsen das Tippen nicht mehr. Nur der erste Aufruf der Vorschläge nach dem Start der Entwicklungsumgebung dauert etwas länger. Fehlermarkierungen und Gliederung erscheinen kurz nach dem Tippen. Betroffene Komponenten: org.eclipse.osbp.xtext.oxtype/org.eclipse.osbp.xtext.oxtype.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.entity.xtext.ui, org.eclipse.osbp.dsl/org.eclipse.osbp.dsl.dto.xtext.ui, org.eclipse.osbp.xtext.statemachine/org.eclipse.osbp.xtext.statemachine.ui, org.eclipse.osbp.xtext.datamart/org.eclipse.osbp.xtext.datamartdsl.ui
		+
		+	* Build & Infrastruktur:
		+	** Änderung: Die Entwicklungsumgebung schreibt bei jedem Bauen nicht mehr die Versionsangaben aus Git in die Projekte. Das hat das Bauen in der Entwicklungsumgebung spürbar verlangsamt und oft eine weitere Baurunde ausgelöst. Die Versionsangaben entstehen weiterhin beim Bauen auf dem Build-Server, die ausgelieferten Stände enthalten sie wie bisher. Entwickler führen danach einmal in der Entwicklungsumgebung „Maven > Update Project“ mit „Force Update of Snapshots“ aus (Alt+F5). Betroffene Komponenten: org.eclipse.osbp.releng.maven, org.eclipse.osbp.releng.maven/org.eclipse.osbp.releng.maven.parent.tycho, org.osbee.releng.maven, org.osbee.releng.maven/org.osbee.releng.maven.parent.tycho, net.osbee.releng.maven, net.osbee.releng.maven/net.osbee.releng.maven.parent.tycho, net.osbee.app.releng.maven, net.osbee.app.releng.maven/net.osbee.app.releng.maven.parent.tycho
		+
		+	== Version 5.3.0.20261105 ==
		+
		+	* OSBP Framework:
		+	** Änderung: Beim Start wird die Datenbankstruktur nur noch geprüft, wenn sich das Datenmodell wirklich geändert hat, auch nach einem Update. Ein neuer Stand der Anwendung ohne Änderung am Datenmodell startet dadurch ohne diese Prüfung. Nach dem Update auf diese Version wird einmalig noch einmal alles geprüft. Bei sehr großen Tabellen kann das viele Minuten dauern. Die Anwendung darf in dieser Zeit nicht beendet werden. Über den echten Update-Fall auf einer Installation ist das noch nicht bestätigt. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Änderung: Der Start wartet jetzt so lange, wie die Prüfung der Datenbankstruktur braucht. Bisher brach er nach 5 Minuten ab, und bei sehr großen Tabellen kam die Anwendung dadurch nicht mehr hoch. Wer weiterhin eine Grenze möchte, setzt <code>-DPersistenceService.startupTimeoutSeconds=<Sekunden></code>. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Änderung: Vorhandene Indizes und Fremdschlüssel werden beim Start auf MySQL und MariaDB nicht mehr ein zweites Mal angelegt. Das verkürzt die Prüfung bei großen Tabellen deutlich. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Fix: Liegen auf einem Datenbankserver mehrere Datenbanken mit gleichen Tabellen, legt die Prüfung auf MySQL und MariaDB fehlende Spalten nun zuverlässig an. Bisher galt eine Spalte als vorhanden, wenn es sie in einer anderen Datenbank gab. Später erschien dann die Meldung „Unknown column“, zum Beispiel beim Wiederholdruck einer Rechnung. Im Betrieb ist diese Korrektur noch nicht bestätigt. Ohne Verbindungspool (<code>-DPersistenceService.connectionPool=false</code>) greift sie nicht. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Neu: Die Startseite zeigt die verstrichene Zeit, damit man sieht, dass der Start noch läuft. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Neu: Die Startseite kann das Ende des Protokolls anzeigen, mit <code>-DStartupStatusPage.showLog=true</code> in der <code>eclipse.ini</code>. Die Datei wird automatisch ermittelt, <code>-DStartupStatusPage.logFile=<Pfad></code> gibt sie fest vor. Die Anzeige ist standardmäßig aus, denn die Startseite ist ohne Anmeldung erreichbar und das Protokoll kann vertrauliche Angaben enthalten. Auf Kassen beim Kunden sollte sie aus bleiben. Betroffene Komponenten: org.eclipse.osbp.ecview.addons/org.eclipse.osbp.ecview.jetty.manager
		+
		+	== Version 5.3.0.20261104 ==
		+
		+	* OSBP Framework:
		+	** Neu: Beim Start wird die Datenbankstruktur nur noch dort geprüft, wo sich das Datenmodell geändert hat. Auf einer Testinstallation war die Datenbank beim Start dadurch rund 18 Sekunden früher bereit; insgesamt entfallen dort rund 30 Sekunden Prüfarbeit. Der erste Start nach einem Update prüft noch einmal alles. Die Prüfung ergänzt nur und entfernt nichts aus der Datenbank. Betroffene Komponenten: org.eclipse.osbp.persistence, org.eclipse.osbp.system.configuration.api, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.base, org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration.service
		+	** Neu: Eine neue Ansicht zeigt, wann die Datenbankstruktur zuletzt geprüft wurde. Administratoren können dort für einen Bereich eine neue Prüfung beim nächsten Start auslösen. Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.configuration
		+	** Änderung: Der Startparameter <code>-DPersistenceService.NoCache</code> wird nicht mehr gebraucht. Ein vorhandener Eintrag stört nicht. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Fix: Ein Bericht wird nach einem Klick nur noch einmal angezeigt. Seit Version 5.3.0.20261103 konnte er sich mehrfach neu aufbauen. Betroffene Komponenten: org.eclipse.osbp.osgi.hybrid.api, org.eclipse.osbp.xtext.report/org.eclipse.osbp.xtext.report.runtime
		+

	== Version 5.3.0.20261103 ==		== Version 5.3.0.20261103 ==

@@ Line 6: / Line 6: @@
 * OSBP Framework:
 ** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. 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: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; 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 <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Flyway verwendet weiter die Datenquelle des Treibers. In der Entwicklungsumgebung gemessen: keine neuen Verbindungen im Ruhezustand, beim stündlichen Lauf und bei Verkäufen. 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 <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> 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: <code>db/README.md</code> 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 (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence
 ** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> 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): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. 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 &lt;Bundle&gt; 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 <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence
 * DSL:

← Older revision		Revision as of 12:05, 4 November 2026
Line 3:		Line 3:
	== [[Releasenotes \| --> zurück zu Releasenotes ]] ==		== [[Releasenotes \| --> zurück zu Releasenotes ]] ==

		+	== Version 5.3.0.20261103 ==

−	~~== Version~~ 5.3.0.~~20261104~~ ==	+	* OSBP Framework:
		+	** 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 <code>SELECT COUNT</code>: 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 (<code>RefreshTimeout</code>, 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 <code>AbstractHybridVaaclipseView</code> (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 <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> 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 (<code>outOfOrder</code>), 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 (<code>EclipseLink/<Unit>#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) 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 (<code>Soft</code>, <code>1000</code>) 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 (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). 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 <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> 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 (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) 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 <code>shipment</code> und <code>pos</code> geschehen). Betroffene Komponenten: org.eclipse.osbp.system.configuration/org.eclipse.osbp.system.monitoring.base
		+	** Neu: Die Pools sind über JMX sichtbar. Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Neu: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code><Persistence Unit>/<Hersteller>/V<Version>__<Beschreibung>.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. 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: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Bisher suchte Flyway über einen Class Loader, der in OSGi einen Ordner wie <code>db/migration</code> nur im eigenen Bundle sieht – Skripte in anderen Bundles wurden nie gefunden. Die neue Klasse <code>BundleMigrations</code> sammelt sie und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.<Datenquelle>.DatabaseMigrationSourcePath</code>) werden wie bisher mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>; 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 <code>database.connectionpool.max</code>, 5 Verbindungen bleiben offen, Austausch nach 30 Minuten. <code>-DPersistenceService.connectionPool=false</code> schaltet den Pool ab; <code>.minIdle</code>, <code>.maxLifetimeMinutes</code> und <code>.leakDetectionSeconds</code> stellen ihn ein. Flyway verwendet weiter die Datenquelle des Treibers. In der Entwicklungsumgebung gemessen: keine neuen Verbindungen im Ruhezustand, beim stündlichen Lauf und bei Verkäufen. 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: <code>db/README.md</code> 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 (<code>2026.10.28.1</code> erschien als <code>2026.10.</code>). Betroffene Komponenten: org.eclipse.osbp.persistence
		+	** Änderung: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> 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): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. 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 <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht. Betroffene Komponenten: org.eclipse.osbp.persistence
		+
		+	* 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 <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> 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

← Older revision		Revision as of 10:46, 4 November 2026
Line 2:		Line 2:

	== [[Releasenotes \| --> zurück zu Releasenotes ]] ==		== [[Releasenotes \| --> zurück zu Releasenotes ]] ==
		+
		+
		+	== Version 5.3.0.20261104 ==
		+

	== Version 5.3.0.20261029 ==		== Version 5.3.0.20261029 ==

@@ Line 7: / Line 7: @@
 * 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 (<code>EclipseLink/&lt;Unit&gt;#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) 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 <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. 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: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>;'''
+** Neu: org.eclipse.osbp.persistence: Flyway findet Datenbankmigrationen, die Bundles mitbringen. Ein Bundle nennt seinen Migrationsordner im Manifest-Header <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code>&lt;Persistence Unit&gt;/&lt;Hersteller&gt;/V&lt;Version&gt;__&lt;Beschreibung&gt;.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. 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: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.&lt;Datenquelle&gt;.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen nur mit <code>-DFlyway.active=true</code>;'''
 ** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> 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): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. Versionen müssen innerhalb eines Bundles eindeutig sein. Scheitern die Migrationen eines Bundles, wird das mit „the migrations of &lt;Bundle&gt; 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 <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht
 ** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> 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 (<code>outOfOrder</code>), 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 (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). 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 <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> 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 (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) 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 <code>shipment</code> und <code>pos</code> geschehen)
+** 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 (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). 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 <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> 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 (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) 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:

← Older revision		Revision as of 10:38, 29 October 2026
Line 2:		Line 2:

	== [[Releasenotes \| --> zurück zu Releasenotes ]] ==		== [[Releasenotes \| --> zurück zu Releasenotes ]] ==
		+
		+	== 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 (<code>EclipseLink/<Unit>#cacheTypeDefault</code>, <code>#cacheSizeDefault</code>) 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 <code>OSBP-Flyway-Migration: db/migration</code> und legt die Skripte als <code><Persistence Unit>/<Hersteller>/V<Version>__<Beschreibung>.sql</code> ab, z.B. <code>monitoringData/mysql/V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>. 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: <code>mysql</code> (auch für MariaDB), <code>postgresql</code>, <code>oracle</code>, <code>sqlserver</code>, <code>h2</code>, <code>derby</code>. Die neue Klasse <code>BundleMigrations</code> sammelt die Migrationsskripte und übergibt sie Flyway als Resource Provider; die Skripte im Dateisystemordner der Datenquelle (<code>-DFlyway.<Datenquelle>.DatabaseMigrationSourcePath</code>) werden mitgelesen. '''Die Migrationen laufen weiterhin nur mit <code>-DFlyway.active=true</code>;'''
		+
		+	** org.eclipse.osbp.persistence: Jedes Bundle mit Migrationen hat eine eigene Historientabelle, <code>flyway_</code> 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): <code>org.eclipse.osbp.system.monitoring.base</code> wird zu <code>flyway_oeos_monitoring_base</code>, <code>net.osbee.app.bdi.ex.model.entity</code> zu <code>flyway_noa_bdi_ex_model_entity</code>. 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 <code>flyway_schema_history</code>; eine Quelle ohne Skripte läuft gar nicht
		+
		+	** Fix: org.eclipse.osbp.persistence: Flyway lief bei jedem Start mit <code>baseline()</code>. Sobald die Historie Einträge hatte, lehnte Flyway das mit einer Ausnahme ab, die verschluckt wurde – <code>migrate()</code> lief danach nie. Eine bestehende Datenbank ohne Historie wird nun über <code>baselineOnMigrate</code> einmalig mit Version 0 versehen. Ebenso entfällt <code>repair()</code> 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 (<code>outOfOrder</code>), 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 (<code>MONITOR_SUB_CATEGORY.MSC_NAME</code>, <code>MONITOR_CATEGORY.MCA_NAME</code> und <code>DK</code>, <code>MONITOR_MAIN_CATEGORY.MMCA_NAME</code>, <code>MONITOR_COMPONENT.MCO_NAME</code>). 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 <code>XRECHNUNG_UP</code> und unter <code>ZUGFERD_UP</code> – scheiterte daher an einem doppelten Schlüssel, <code>MonitoringService</code> 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 (<code>V2026.10.28.1__drop_stale_monitor_unique_indexes.sql</code>, für MySQL/MariaDB, PostgreSQL und Oracle) entfernt diese Indizes; <code>MONITOR_COMPONENTI1</code> legt die Schemagenerierung danach in der Form des Modells (<code>MCO_NAME, MCO_INSTALLATION</code>) 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 <code>shipment</code> und <code>pos</code> geschehen)
		+
		+	* Allgemein:
		+	** Hinweis für Produkte mit REST-Diensten über ECF: Das Bundle <code>org.eclipse.ecf.osgi.services.remoteserviceadmin.console</code> (Konsolenbefehle <code>rsa …</code>) sollte nicht automatisch starten. Seine Komponente <code>RSACommand</code> benötigt den <code>RemoteServiceAdmin</code>; während ECF diesen beim Export der Dienste erzeugt, blockieren sich ECF und DS gegenseitig, bis DS nach seiner Wartezeit (<code>-Dequinox.scr.waitTimeOnBlock</code>, in BDI 20 s) abbricht. In BDI und im CX-Portal ist es auf <code>autoStart="false"</code> 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 <code>flyway-mysql</code>, das sich über <code>META-INF/services</code> registriert und von Flyway mit dessen eigenem Class Loader gesucht wird. Das Modul wird daher als Fragment <code>org.flywaydb.database.mysql</code> 9.14.0.v20261028 an <code>org.flywaydb.core</code> ausgeliefert (das Manifest des Originals nennt sich selbst <code>org.flywaydb.core</code> und ist so nicht verwendbar) und mit dem Feature <code>org.eclipse.osbp.dependencies.feature.flyway</code> verteilt.
		+

	== Version 5.3.0.20261012 ==		== Version 5.3.0.20261012 ==