Migration MyCoRe LTS 2025.12 nach 2026.06

Diese Seite fasst Systemanforderungen für die Nutzung des MyCoRe LTS 2026.06 und die Migration von Version 2025.12 zu 2026.06 zusammen.

Systemanforderungen MyCoRe LTS 2026.06 [TODO: UPDATE]

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

Betriebssystem

MyCoRe LTS 2026.06 ist auf diesen Betriebssystemen 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 2026.06 sind folgende Softwarekomponenten erforderlich bzw. empfohlen. Diese sind alle von Drittanbietern und im Normalfall in den Distributionen enthalten.

• Java 25 (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

• Das Benennungsschema zum Instanziieren von konfigurierten Komponenten wurde vereinheitlicht.
• Anpassung des Standardverhaltens von @MCRPostConstruction.

Verhaltensänderung von MCRCronjob (MCR-3560)

Bisher wurden in MyCoRe konfigurierte Cronjobs bei einer Exception im Job nicht mehr gemäß des CRON-Zeitplans neu geplant. Ab dieser Version führt ein Fehler im Job nicht mehr zum vollständigen Abbruch des Zeitplans. Ein Retry-Mechanismus für die erneute Ausführung des aktuellen Joblaufs ist weiterhin nicht vorgesehen.

Überarbeitung der Solr-Integration (MCR-3645)

Die Solr-Integration wurde grundlegend refaktoriert. Das bisherige Konzept mit MCRSolrCore und MCRSolrCoreManager wurde durch ein neues, klassenbasiertes Index-Registry-Konzept ersetzt. Dabei wurden sowohl die Property-Namen als auch die Java-API geändert. Die bisherigen Properties werden als deprecated erkannt und führen zu einer Warnung im Log, bleiben aber zunächst noch funktionsfähig.

• Die Konfiguration der Solr-Kerne erfolgt nun über MCR.Solr.IndexRegistry.Index.{id}.* statt MCR.Solr.Core.{id}.*.
• Der Verbindungstyp (Standalone / SolrCloud) wird über eine Class-Property explizit festgelegt.
• Client-Timeouts und Parallelisierungs-Properties wurden unter MCR.Solr.Default.* zusammengefasst.
• Die Java-Klassen MCRSolrClientFactory und MCRSolrCoreManager sind deprecated und werden mit dem nächsten Release entfernt.

Migrationsschritte

MCRAccessKeyServiceFactory ist deprecated (MCR-3581)

Mit MCR-3581 wurde die gesamte Factory-Klasse MCRAccessKeyServiceFactory als @Deprecated(forRemoval = true) markiert.

Alle bisherigen Factory-Methoden sollten ersetzt werden:

• ALT: MCRAccessKeyService aks = MCRAccessKeyServiceFactory.getAccessKeyService();
• NEU: `MCRAccessKeyService aks = MCRAccessKeyService.obtainInstance();

Weitere Factory-Methoden wurden analog verschoben:

• ALT: MCRAccessKeyServiceFactory.getAccessKeySessionService()
• NEU: MCRAccessKeySessionService.obtainInstance()

• ALT: MCRAccessKeyServiceFactory.getAccessKeyPermissionService()
• NEU: MCRAccessKeyPermissionService.obtainInstance()

MCRCategoryID: Umbenennung der Methode isRootID() zu isRoot()

Wegen eines Konfliktes bei der Benennung der beiden Methoden isRootID() und getRootID() im Zusammenhang mit der Verwendung der Klasse als JavaBean wurde die Methode isRootID() zu isRoot() umbenannt (siehe Ticket MCR-3637).

Umwandlung von MCRXMLMetadataManager in ein Interface (MCR-3600)

Bisher war MCRXMLMetadataManager eine finale Klasse. Die konkrete Implementierung konnte ausgetauscht werden, indem per MCR.Metadata.Manager eine Instanz von MCRXMLMetadataManagerAdapter angegeben wurde. Damit war MCRXMLMetadataManager die einzige Stelle in MyCoRe, die dieses Adapter-Pattern verwendet hat. Zur Harmonisierung wurde daher MCRXMLMetadataManager in ein Interface umgewandelt.

Die bestehenden Implementierungen implementieren nun direkt MCRXMLMetadataManager und nicht mehr MCRXMLMetadataManagerAdapter. Sie wurden daher wie folgt umbeannnt:

• MCRDefaultXMLMetadataManagerAdapter ⮕ MCRDefaultXMLMetadataManager
• MCRGZIPOCFLXMLMetadataManagerAdapter ⮕ MCRGZIPOCFLXMLMetadataManager
• MCROCFLXMLMetadataManagerAdapter ⮕ MCROCFLXMLMetadataManager

Es wurde jeweils eine weitere Klasse mit dem alten Namen hinzugefügt und als @Deprecated markiert. Im Kommentar zur Klasse wird jeweils auf die nun zu verwendende Klasse hingewiesen. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung des nächsten MyCoRe-Releases umgestellt werden.

Um den PMD-Regeln für Singeltons gerecht zu werden wurde zudem die Methode MCRXMLMetadataManager#getInstance in MCRXMLMetadataManager#obtainInstance umbenannt und die alte Methode ebenfalls als @Deprecated markiert. Auch sie wird mit dem nächsten Release entfernt.

Solr-Konfiguration migrieren (MCR-3645)

Property-Umbenennung

Die folgende Tabelle zeigt die alten Properties und ihre neuen Entsprechungen. Ob CoreName oder CollectionName zu verwenden ist, hängt vom Betriebsmodus ab (Standalone vs. SolrCloud). Ebenso ob SolrUrl (Standalone), SolrUrls (SolrCloud URL-Modus) oder ZkUrls (SolrCloud ZooKeeper-Modus) gesetzt werden muss.

Pflicht-Property: Class

Neu ist das Property MCR.Solr.IndexRegistry.Index.{id}.Class, das den Verbindungstyp explizit festlegt. Es muss für jeden konfigurierten Index gesetzt werden:

# Standalone Solr
MCR.Solr.IndexRegistry.Index.main.Class=org.mycore.solr.standalone.core.MCRConfigurableSolrCore

# SolrCloud (URL-basiert oder ZooKeeper)
MCR.Solr.IndexRegistry.Index.main.Class=org.mycore.solr.cloud.collection.MCRConfigurableSolrCloudCollection

Minimales Migrationsbeispiel

Eine typische Standalone-Konfiguration sah bisher so aus:

# ALT (bis 2025.12)
MCR.Solr.ServerURL=http://localhost:8983/
MCR.Solr.Core.main.Name=mycore
MCR.Solr.Core.classification.Name=mycore-classifications

Die neue Konfiguration lautet:

# NEU (ab 2026.06)
MCR.Solr.IndexRegistry.Index.main.Class=org.mycore.solr.standalone.core.MCRConfigurableSolrCore
MCR.Solr.IndexRegistry.Index.main.SolrUrl=http://localhost:8983/solr
MCR.Solr.IndexRegistry.Index.main.CoreName=mycore

MCR.Solr.IndexRegistry.Index.classification.Class=org.mycore.solr.standalone.core.MCRConfigurableSolrCore
MCR.Solr.IndexRegistry.Index.classification.SolrUrl=http://localhost:8983/solr
MCR.Solr.IndexRegistry.Index.classification.CoreName=mycore-classifications

Den Konfigurationsassistenten zum Erzeugen der Properties für alle Verbindungstypen findet man in der Solr-Dokumentation.

Java API: MCRSolrClientFactory und MCRSolrCoreManager

Die Klassen MCRSolrClientFactory und MCRSolrCoreManager sind deprecated. Der Zugriff auf Solr-Clients erfolgt nun über die Index-Registry:

// ALT (bis 2025.12)
SolrClient client = MCRSolrClientFactory.getMainSolrClient();
// oder:
SolrClient client = MCRSolrCoreManager.get("main").get().getClient();

// NEU (ab 2026.06)
SolrClient client = MCRSolrIndexRegistryManager.obtainRegistry()
    .getIndex("main")
    .orElseThrow()
    .getClient();

Java API: MCRSolrAuthenticationManager

Die Methode MCRSolrAuthenticationManager.getInstance() wurde in MCRSolrAuthenticationManager.obtainInstance() umbenannt.

// ALT
MCRSolrAuthenticationManager.getInstance().applyAuthentication(request, level);

// NEU
MCRSolrAuthenticationManager.obtainInstance().applyAuthentication(request, level);

Anpassung des Standardverhaltens von der annotationsbasierten Konfiguration (MCR-3646)

Ebenfalls mit MCR-3646 wurde Standardverhaltens von @MCRInstance, @MCRInstanceMap und @MCRInstanceList angeglichen und abgerundet; insbesondere unter Betrachtung der vielen Kombinationsmöglichkeiten bzgl.

• der verschiedenen Konfigurationsmöglichkeiten von @MCRSentinel,
• redundanten Konfigurationseinträgen und
• ob Instanzen optional oder notwendig sind.

Hierbei wurden das Verhalten einiger (in der Praxis vermutlich selten bis nie vorkommender) Randfälle angepasst, insbesondere solcher, bei denen keine Konfigurationswerte vorhanden sind. Wo früher eine Exception geworfen wurde, wird nun z.B. eine Leere Map oder List generiert, oder umgekehrt. In der Ticket-Beschreibung sind das aktuelle Verhalten und alle Verhaltensänderungen ausführlich beschrieben.

Die Konfiguration eigener Anwendungen muss ggf. angepasst werden.

Benennungsschema zum Instanziieren von konfigurierten Komponenten (MCR-3670)

Bisher gab es mehrere Varianten bei der Benennung des Properties für den Klassennamen einer konfigurierbaren Komponente (mit Suffix .Class oder .class oder ohne Suffix). Mit MCR-3670 wurde das Benennungsschema vereinheitlicht. Es wird nun nur noch die Variante mit Suffix .Class verwendet. Die Unterstützung für die anderen beiden Varianten wurde entfernt. Entsprechend wurden diverse Properties umbenannt.

Jetzt gilt allgemein:

Eine Komponente mit Namen MCR.Example wird mit z.B. MCRConfiguration2.getInstanceOf(MCRExample.class, "MCR.Example") instanziiert.

In den Properties muss für diese Komponente ein Eintrag mit Namen Class für diese Komponente vorhanden sein, in dem der Klassenname der zu instanziierenden Klasse steht, also z.B. MCR.Example.Class=my.example.MyExample.class.

Dies erfordert zwei Migrationsschritte:

1. Wer betroffene Properties in eigenen Modulen gesetzt oder überschrieben hat, muss dort die Namen entsprechend anpassen.
2. Wer in eigenem Java-Code konfigurierte Komponenten instanziiert, muss seinen Code ggf. auf die einzige nun unterstützte Variante umstellen und seine eigenen Properties entsprechend umbenennen.

In diesem Zusammenhang wurde zudem MCRConfiguration2#getInstantiatablePropertyKeys dahingehend angepasst, dass die Komponentennamen (ohne Suffix .Class) zurückgeliefert werden. Eigener Java-Code muss ggf. angepasst werden.

Anpassung des Standardverhaltens von @MCRPostConstruction (MCR-3670)

Ebenfalls mit MCR-3670 wurde Standardverhaltens von @MCRPostConstruction angepasst. Es wird nun standardmäßig der Name der Komponente (ohne Suffix .Class) als Wert geliefert, nicht mehr der Name des Properties, dass den Klassennamen beinhaltet (mit Suffix .Class).

Eigener Java-Code sollt oder muss ggf. angepasst werden:

• @MCRPostConstruction(MCRPostConstruction.Value.CANONICAL) kann zu @MCRPostConstruction vereinfacht werden.
• @MCRPostConstruction muss entweder zu @MCRPostConstruction(MCRPostConstruction.Value.ACTUAL) geändert werden, oder der Code, der den Property-Namen verarbeitet, muss angepasst werden.

URI Resolver Refactoring (MCR-3688)

Im Rahmen dieses Refactorings wurde primär die zentrale MCRURIResolver-Klasse refactored und in ein neues Paket verlegt.
Durch die Auslagerung der bisherigen Resolver-Logik aus MCRURIResolver in eigenständige URI Resolver Module/Klassen, die als Configurable Instances geladen werden, sind alle nun über Properties individuell überschreibbar und können so gezielt durch eigene Implementierungen ersetzt werden.

Dazu wurden ggf. Klassen in dedizierte Pakete verschoben und umbenannt. Die alten Klassen und Methoden sind als @Deprecated markiert und werden in einer späteren Version entfernt.

Hinweis: Sofern keine URI-Resolver-Module anderweitig eingesetzt oder genutzt werden, keine zugehörigen Properties überschrieben und keine zusätzlichen Properties definiert wurden, ist keine Migration notwendig.

1. Neues Paket für MCRURIResolver

Die zentrale Resolver-Klasse hat ein neues Paket erhalten:

• org.mycore.common.xml.MCRURIResolver ⮕ org.mycore.common.xsl.uriresolver.MCRURIResolver
• org.mycore.common.xml.MCRURIResolverFilter ⮕ org.mycore.common.xsl.uriresolver.MCRURIResolverFilter

Aktion: Alle Java-Importe aktualisieren.

2. Weitere Resolver in neue Pakete verschoben / umbenannte Klassen

Alle eigenständigen URI Resolver aus mycore-base wurden aus ihren bisherigen Paketen in dedizierte Pakete verschoben. Die Klassen selbst existieren weiterhin an den alten Stellen, sind aber als @Deprecated markiert.

Die folgenden Klassen wurden zusätzlich umbenannt:

• MCRUserAndObjectRightsURIResolver ⮕ MCRUserObjectRightsURIResolver
• MCRCryptResolver ⮕ MCRCryptURIResolver
• MCRLanguageResolver ⮕ MCRLanguageURIResolver
• MCRBasketResolver ⮕ MCRBasketURIResolver
• MCRStaticContentResolver ⮕ MCRStaticContentURIResolver

Aktion: Direkte Verwendungen dieser Klassen (z. B. in mycore.properties oder Java-Code) auf die neuen Namen / Pakete umstellen.

3. Anpassung mycore.properties

URI Resolver Module werden nun als Configurable Instances geladen. Das bedeutet, dass der Wert der Property zwingend einen vollqualifizierten Klassennamen enthalten muss (. Class-Suffix). Werden eigene oder überschriebene Properties noch im alten Format ohne .Class-Suffix definiert, müssen diese entsprechend angepasst werden.

Eventuell werden URI Resolver nun direkt konfiguriert. Dies betrifft vor allem die folgenden URI Resolver:

• classification (MCR.URIResolver.ModuleResolver.classification.Class)
• http/https (MCR.URIResolver.ModuleResolver.http.Class / MCR.URIResolver.ModuleResolver.https.Class)
• xslStyle (MCR.URIResolver.ModuleResolver.xslStyle.Class)

Empfehlung: Log beim Hochfahren auf Deprecation-Warnungen prüfen.

Aktion: Ggf. eigene mycore.properties und alle Properties die MCR.URIResolver.ModuleResolver.*= setzen auf .Class-Suffix umstellen.

4. Neue Hilfsklassen

Im neuen Paket org.mycore.common.xsl.uriresolver stehen neue Hilfsklassen zur Verfügung, die bei der Implementierung eigener URI Resolver genutzt werden sollten:

• MCRURIResolverHelper: Hilfsmethoden, z. B. zum Parsen von Query-Parametern (parseQueryParameters(String))
• MCRURIResolverResponse: Fabrikmethoden für häufige XML-Antworttypen (z. B. ofBoolean(boolean))

Aktion: Optional Hilfsklassen in bestehenden Implementierungen nutzen.