Migration MyCoRe LTS 2025.06 nach 2025.12

Systemanforderungen MyCoRe LTS 2025.12

Für den Betrieb einer MyCoRe-Anwendung unter LTS 2025.12 sind folgende Voraussetzungen zu erfüllen:

Betriebssystem

MyCoRe LTS 2025 ist auf diesen Betriebsystemen im Einsatz. Höhere Versionen sollten kein Problem darstellen.

• Open SuSE Leap 15.6 oder höher
• SuSE SLES 15.6 oder höher
• Ubuntu 24.04 LTS
• CentOS 8
• RHEL 8
• Windows 11 für Test- und Entwicklungssysteme

Standardsoftware

Zur Arbeit mit MyCoRe LTS 2025 sind folgende Softwarekomponenten erforderlich bzw. empfohlen. Diese sind alle von Drittanbietern und im Normalfall in den Distributionen enthalten.

• Java 21 (OpenJDK) (muss ggf. extern nachinstalliert werden)
• Tomcat 10.1.x bzw. Jetty 11.x (alternativ ein System mit Unterstützung von Servlet-6.0 und JakartaEE)
• SOLR 9.8.1 oder höher
• eine hibernate-fähige relationale Datenbank wie PostgreSQL 16 oder höher , MySQL/Maria-DB 10 oder höher, DB2; für Testzwecke genügt auch die integrierte Datenbank H2
• Git 2.26 oder höher
• Apache Maven 3.6.3 oder höher

Neuerungen

... die eine Migration erforderlich machen

API-Anpassungen

• Die Methode MCRAccessControlSystem#instance() wurde umbenannt (siehe unten).

Umstellung auf das normalisierte Datenmodell und den Object Expander

Mit diesen Änderungen führt das MyCoRe-Framework ein neues, robusteres und performanteres System zur Handhabung von Objektmetadaten ein. Das Kernkonzept ist die Trennung zwischen normalisierten und expandierten Objekten.

Normalisierte vs. Expandierte Objekte:

• Normalisiertes Objekt (MCRObject): Dies ist die Form, in der Objekte jetzt in der Datenbank (XML-Store) gespeichert werden. Sie enthalten keine redundanten Informationen mehr. Insbesondere sind die Listen von Kindern (<children>) und Derivaten (<derobjects>) nicht mehr Teil der MCRObjectStructure. Diese Informationen werden nun zentral und konsistent über den MCRLinkTableManager verwaltet.
• Expandiertes Objekt (MCRExpandedObject): Dies ist eine angereicherte, denormalisierte In-Memory-Repräsentation eines Objekts. Sie wird zur Laufzeit für Anzeigezwecke (z. B. in XSLT-Transformationen), für die Indexierung (Solr) oder in APIs verwendet. Sie enthält die vollständigen Informationen, einschließlich Kinder, Derivate und von Eltern geerbte Metadaten.

Der MCRExpandedObjectManager und Caching

• Der neue MCRExpandedObjectManager ist die zentrale Anlaufstelle, um ein expandiertes Objekt zu erhalten (MCRExpandedObjectManager.getInstance().getExpandedObject(obj)).
• Expandierte Objekte werden in einem Dateisystem-basierten Cache (MCRExpandedObjectCache) zwischengespeichert, um die Performance drastisch zu verbessern. Der Cache wird durch Event Handler automatisch invalidiert, wenn sich ein Objekt oder seine verknüpften Objekte ändern.

Event-basierte Aktualisierungen statt Metadata-Share-Agent:

• Das alte MCRMetadataShareAgent-System zur Vererbung von Metadaten wurde vollständig entfernt.
• Die Aktualisierung von abhängigen Objekten (z.B. Kinder, wenn sich ein Elternteil ändert) erfolgt nun über neue Events wie ANCESTOR_UPDATED und LINKED_UPDATED.
• Diese Events führen zur Invalidierung des Caches für die betroffenen Objekte, die dann bei der nächsten Anforderung neu expandiert werden.

Normalisierungs- und Validierungs-Framework

• Es wurde ein konfigurierbares Framework eingeführt, um Objekte vor dem Speichern zu normalisieren und zu validieren. Dies sorgt für eine höhere Datenkonsistenz. Normalizer entfernen z.B. automatisch generierte Klassifikationen oder leeren die relatedItem-Struktur in MODS-Objekten, bevor diese gespeichert werden.

Migrationsschritte

• API-Änderungen im Code beachten (Breaking Changes!)
  Der meiste Anpassungsbedarf wird in Ihrem eigenen Code entstehen, der auf die MyCoRe-Datenstrukturen zugreift.

  Zugriff auf Kinder und Derivate:
  • ALT: mcrObject.getStructure().getChildren() oder mcrObject.getStructure().getDerivates()
  • NEU: Diese Methoden existieren auf MCRObjectStructure nicht mehr. Verwenden Sie stattdessen:
    • Um die IDs zu erhalten (empfohlen und performant):

      1 2	List<MCRObjectID> childrenIDs = MCRMetadataManager.getChildren(mcrObject.getId()); List<MCRObjectID> derivateIDs = MCRMetadataManager.getDerivateIds(mcrObject.getId());

    • Um die vollständigen Link-Objekte (MCRMetaLinkID) zu erhalten, verwenden Sie die statische Methode MCRMetadataManager#retrieveMCRExpandedObject, die die Daten aus dem Cache lädt:

      1 2 3

      MCRExpandedObject expObject = MCRMetadataManager.retrieveMCRExpandedObject(mcrObject.getId()); List<MCRMetaLinkID> children = expObject.getStructure().getChildren(); List<MCRMetaEnrichedLinkID> derivates = expObject.getStructure().getDerivates();

    • Alternativ kann der MCRExpandedObjectManager verwendet werden, wobei die Daten live ergänzt werden:

      1 2 3

      MCRExpandedObject expObject = MCRExpandedObjectManager.getInstance().getExpandedObject(mcrObject); List<MCRMetaLinkID> children = expObject.getStructure().getChildren(); List<MCRMetaEnrichedLinkID> derivates = expObject.getStructure().getDerivates();

  MCRMetadataManager API-Vereinfachung:
  • Methoden mit Zeitstempel-basiertem Caching wurden entfernt.
  • ALT: MCRMetadataManager.getDerivateIds(objectId, 10, TimeUnit.SECONDS)
  • NEU: MCRMetadataManager.getDerivateIds(objectId)
  • ALT: MCRMetadataManager.getObjectId(derivateId, 10, TimeUnit.SECONDS)
  • NEU: MCRMetadataManager.getObjectId(derivateId)
  MCRLinkTableManager:
  • Anstelle von String-Konstanten für Link-Typen (z.B. parent, derivate) wird nun das Enum MCRLinkType verwendet.
  • ALT: ltm.getSourceOf(id, "parent")
  • NEU: ltm.getSourceOf(id, MCRLinkType.PARENT)

• Datenmigration durchführen
  Ihre bestehenden XML-Daten in der Datenbank enthalten noch die alten, nicht-normalisierten Strukturen (<children> und <derobjects>). Diese müssen migriert werden.

  CLI-Befehl zur Migration:
  Es wurde ein neuer CLI-Befehl eingeführt, um ein einzelnes Objekt zu migrieren:
  migrate to normalized object {id}
  Migrationsstrategie für Kind-Reihenfolge:
  • Der Migrationsbefehl entfernt die redundanten <children> und <derobjects> aus der XML-Struktur.
  • Die alte <children>-Liste enthielt eine implizite Reihenfolge. Sie können steuern, ob diese erhalten bleiben soll, indem Sie eine Strategie festlegen:

    1 2 3 4 5 6 7

    # Behält die Reihenfolge in einem neuen <childrenOrder>-Element. # Gut, wenn die Reihenfolge wichtig war. MCR.Migration.ChildrenOrder.Strategy=org.mycore.migration.strategy.MCRAlwaysAddChildrenOrderStrategy # Standard: Entfernt die Kinderliste ohne sie zu überführen. # Sicher, wenn die Reihenfolge nie eine Rolle gespielt hat. # MCR.Migration.ChildrenOrder.Strategy=org.mycore.migration.strategy.MCRNeverAddChildrenOrderStrategy

  Vorgehen:
  • Für eine vollständige Datenmigration müssen mehrere Kommandos ausgeführt werden:
    1. select objects with xpath /mycoreobject - um alle Objekte auszuwählen.
    2. execute for selected migrate to normalized object {x} - um die Migration für jedes ausgewählte Objekt auszuführen.
    3. execute for selected repair metadata search of ID {x} - um die Metadaten für jedes ausgewählte Objekt zu korrigieren.
    4. repair metadata search of type derivate - um die Metadaten für alle Derivate zu korrigieren.
  • Wichtig: Führen Sie diesen Schritt erst aus, nachdem Sie Ihre Konfiguration und Ihren Code angepasst haben.

• Bei allen MyCoRe-Modulen wurden die Tests von JUnit 4 auf JUnit 5 umgestellt. Die Unterstützung für JUnit 4 wurde entfernt. Dementsprechend sind auch die Test-Basisklassen MCRTestCase, MCRJPATestCase und MCRStoreTestCase entfernt worden. Wer in eigenen Modulen JUnit 4 Test hat, muss diese entsprechend anpassen.

  • Statt MCRTestCase zu erweitern, kann die Annotation @MyCoReTest verwendet werden.
  • Statt MCRJPATestCase zu erweitern, kann zusätzlich zu @MyCoReTest die Annotation @ExtendWith(MCRJPAExtension.class) verwendet werden. Für einige Methoden der entfallenen Test-Basisklasse gibt es Ersatz in der Hilfsklasse MCRJPATestHelper (z.B. beginTransaction und endTransaction).
  • Statt MCRStoreTestCase zu erweitern, kann je nach Funktionsbedarf zusätzlich zu @MyCoReTest die Annotation
    @ExtendWith(MCRStoreExtension.class) oder @ExtendWith({MCRJPATestExtension, MCRStoreExtension.class})
    verwendet werden.
  
  

  Statt getTestProperties() zu überschreiben, kann mit @MCRTestConfiguration oder, wenn die Werte dynamisch sind, direkt mit MCRConfiguration2#set gearbeitet werden.

  Bestehende setUp- und tearDown-Methoden können erhalten bleiben, müssen aber als static markiert werden und mit @BeforeAll bzw. @AfterAll annotiert werden. Der Aufruf der jeweiligen Super-Methode sowie eine ggf. vorhandene @Override-Annotation können ersatzlos entfernt werden.

  Wer seine JUnit 4 Tests nicht während der Migration umstellen möchte, kann vorerst auch das neue Modul mycore-junit4 einbinden und die Migration später durchführen. Mit diesem Modul bleiben die oben genannten Test-Basisklassen zunächst noch erhalten. Zudem muss JUnit 4 als Abhängigkeit erhalten bleiben.

  1 2 3 4 5 6 7 8 9 10

  <dependency> <groupId>org.mycore</groupId> <artifactId>mycore-junit4</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> </dependency>

  Die Test-Basisklassen sind im neuen Modul mycore-junit4 als @Deprecated markiert. Im eigenen Modul muss daher innerhalb von <properties> vorübergehend der Eintrag <maven.compiler.arg/> hinzugefügt werden. Dies überschreibt die Standardeinstellung von MyCoRe (<maven.compiler.arg/>-Werror</maven.compiler.arg/>) und erlaubt damit die Verwendung von derart markiertem Code.

  Dieses Modul soll nur vorübergehend die Migration eigener Tests erleichtern wird mit dem nächsten Release von MyCoRe wieder entfernt.

• Die Unterstützung der indirekte Instanziierung von Event-Handlern wird mit dem nächsten Release von MyCoRe entfernt. Hierbei handelt es sich um eigene Implementierungen von MCREventHandlerInitializer im Kombination mit einer Konfigurationen der folgenden Art:

  1 2	MCR.EventHandler.MCRObject.042.MyCustomMode MCR.EventHandler.MyCustomMode=my.custom.CustomEventHandlerInitializer

  Wer diesen Mechanismus bisher nutzt, sollte bereits mit diesem Release auf die direkte Instanziierung umstellen.

• Im Nachgang zu den Änderungen in 2025.06 wurde nun auch die Methode MCRAccessControlSystem#instance() in MCRAccessControlSystem#getInstance() umbenannt. Die alte Methode wurde als @Deprecated markiert. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung der nächsten MyCoRe-Version umgestellt werden.