MyCoRe Logo
Deutsch English
2025.06

Migration MyCoRe LTS 2024.06 nach 2025.06

Diese Seite fasst Systemanforderungen fĂĽr die Nutzung des MyCoRe LTS 2025.06 und die Migration von Version 2024.06 zu 2025.06 zusammen.

Diese Seite ist Work in Progress.
Sie wird im Rahmen der Fertigstellung des aktuellen MyCoRe-Releases weiter ergänzt!

Systemanforderungen MyCoRe LTS 2025.06

FĂĽr den Betrieb einer MyCoRe-Anwendung unter LTS 2025.06 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

  • Bootstrap-Migration
  • Das in MyCoRe verwendete Regelwerk fĂĽr das zur statischen Quellcodeanalyse eingesetzte Programm PMD wurden ĂĽberarbeitet. Dies hat Auswirkungen auf eigene MyCoRe-Module, da viele bestehende Methoden als @Deprecated markiert wurden. Zudem mĂĽssen die angepassten Regeln eingehalten werden, wenn man sein Projekt so konfiguriert hat, dass die fĂĽr MyCoRe geltenden Regeln ebenfalls eingehalten werden sollen. Insbesondere in diesem Zusammenhang wurden einige Methoden und Klassen umbenannt (siehe unten).
  • Die Klasse MCRSystemUserInformation wurde in ein Enum umgewandelt (siehe unten).
  • Die Klasse MCRResourceException wurde in ein entfernt (siehe unten).
  • Bei konfigurierbare Klasseninstanzen wurde die Art und Weise, wie Factory-Methoden gefunden werden und wie Maps von Properties verarbeitet werden, ĂĽberarbeitet (siehe unten).
  • Das Erstellen von Kopien von Instanzen von MCRUser wurde verändert (siehe unten).
  • Das Property MCR.Persistence.Rule.Store_Class wurde in MCR.Persistence.Rule.Store.Class umbenannt.

Migrationsschritte

  • Die wohl wesentlichste Ă„nderung im Zusammenhang mit den neuen PMD-Regeln ist das Benennungsschema fĂĽr Methoden, die im weitesten Sinne als "statische Factory-Methoden" aufgefasst werden können (also nicht zwingend nach der GoF-Definition). Dies sind statische Methoden, die ein Objekt vom Typ ihrer umschlieĂźenden Klasse zurĂĽckliefern.

    Insbesondere die zahlreichen Zugriffsmethoden fĂĽr Singleton-Instanzen fallen in diese Kategorie. Diese hieĂźen bisher zumeist instance() oder getInstance(). Zugleich gab es bisher viele Methode mit Namen getInstance(), die keine Zugriffsmethoden fĂĽr Singleton-Instanzen waren. PMD verschreibt jedoch, dass der Name getInstance() ausschlieĂźlich fĂĽr Zugriffsmethoden fĂĽr Singleton-Instanzen zu verwenden ist.

    FĂĽr MyCoRe wurde das folgende Benennungsschema definiert:

    • getInstance(): Zugriffsmethode fĂĽr Singleton-Instanz
    • createInstance(), createInstance(...): Methode die garantiert eine neue Instanz zurĂĽckliefert
    • obtainInstance(), obtainInstance(...): Methode die nicht unbedingt eine neue Instanz zurĂĽckliefert
    • of(), ofXXX(), of(...), ofXXX(...): Fabrikmethode fĂĽr "Value-artige" Klassen (neuerdings jedoch eher als record implementiert).
    • fromXXX(...): Fabrikmethode fĂĽr Enums und "Enum-artige" Klassen.

    Der Name createInstance wird nur verwendet, wenn die Eigenschaft, dass bei jedem Aufruf garantiert eine neue Instanz erzeugt wird, für den aufrufenden Code von Bedeutung ist. Andernfalls wird der Name obtainInstance verwendet. Letzterer sollte daher bevorzugt werden, auch wenn die aktuelle Implementierung jedes Mal eine neue Instanz erzeugt. Dies lässt zukünftige Änderungen (z.B. Caching der erzeugten Instanzen) zu.

    Alle Methoden, die diesem Benennungsschema nicht gerecht wurden, wurden umbenannt. Zudem wurde jeweils eine weitere Methode mit dem alten Namen hinzugefügt und als @Deprecated markiert. Im Kommentar zur Methode wird jeweils auf die nun zu verwendende Methode hingewiesen. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung der nächsten MyCoRe-Version umgestellt werden.

    In wenigen Fällen wurden für Fabrikmethoden auch semantische Bezeichnungen wie now() oder parseXml() beibehalten oder die Fabrikmethode durch einen entsprechenden Konstruktor ersetzt.

  • Mit der Umstellung der PMD Regeln werden nun alle serialisierbaren Klassen wie folgendermaĂźen gekennzeichnet: 

    1
2

    @Serial
private static final long serialVersionUID = 1L;
    Dies muss in eigenen Klassen ebenfalls umgestellt werden wenn man sein Projekt so konfiguriert hat, dass die fĂĽr MyCoRe geltenden Regeln ebenfalls eingehalten werden sollen.

  • Mit der Umstellung der PMD Regeln werden nun alle Logger folgendermaĂźen erstellt: 

    1

     private static final Logger LOGGER = LogManager.getLogger();

    Einzig in abstrakten Klassen ist auch folgende Variante erlaubt und bei neuem Code bevorzugt zu verwenden: 

    1

     protected final Logger logger = LogManager.getLogger(getClass());
    Dies muss in eigenen Klassen ebenfalls umgestellt werden, wenn man sein Projekt so konfiguriert hat, dass die fĂĽr MyCoRe geltenden Regeln ebenfalls eingehalten werden sollen.

  • Unabhängig von den PMD-Regeln wurden die folgenden Methoden umbenannt oder minimal modifiziert:

    • MCRMetaHistoryItem#getInternalid() ⮕ MCRMetaHistoryItem#getInternalId()
    • MCRMetaHistoryItem#setInternalid(long) ⮕ MCRMetaHistoryItem#setInternalId(long)
    • MCRMetaHistoryItem#createdNow(MCRObjectId) ⮕ MCRMetaHistoryItem#now(MCRObjectId, MCRMetadataHistoryEventType)
    • MCRMetaHistoryItem#deletedNow(MCRObjectId) ⮕ MCRMetaHistoryItem#now(MCRObjectId, MCRMetadataHistoryEventType)
    • MCRConfiguration2#getInstances(String) ⮕ MCRConfiguration2#getInstance(Class, String)
    • MCRConfiguration2#instantiateClass(String) ⮕ MCRConfiguration2#instantiateClass(Class, String)
    • MCRConfigurableInstanceHelper#getInstance(String) ⮕ MCRConfigurableInstanceHelper#getInstance(Class, String)
    • MCRConfigurableInstanceHelper#getInstance(MCRInstanceConfiguration) ⮕ MCRConfigurableInstanceHelper#getInstance(MCRInstanceConfiguration, String)
    • MCRAccessException#missingPrivilege(...) ⮕ MCRMissingPrivilegeException#new(...)
    • MCRAccessException#missingPermission(...) ⮕ MCRMissingPermissionException#new(...)
    • MCRUser#getPassword() ⮕ MCRUser#getHash()
    • MCRUser#setPassword(String) ⮕ MCRUser#setHash(String)
    • MCRUser#getEMailAddress() ⮕ MCRUser#getEMail()
    • MCRPersistenceHelper#getWebPage(ServletContext, String, String) ⮕ MCRPersistenceHelper#getWebPage(String, String)

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

  • Die Klasse MCRSystemUserInformation wurde in ein Enum umgewandelt. Folgende Methoden wurden dabei durch Enum-Konstanten ersetzt:

    • MCRSystemUserInformation#getGuestInstance() ⮕ MCRSystemUserInformation#GUEST
    • MCRSystemUserInformation#getJanitorInstance() ⮕ MCRSystemUserInformation#JANITOR
    • MCRSystemUserInformation#getSystemInstance() ⮕ MCRSystemUserInformation#SYSTEM_USER
    • MCRSystemUserInformation#getSuperUserInstance() ⮕ MCRSystemUserInformation#SUPER_USER

    Die bestehenden Methoden wurden jeweils beibehalten und als @Deprecated markiert. Im Kommentar zur Methode wird jeweils auf die nun zu verwendende Konstante hingewiesen. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung der nächsten MyCoRe-Version umgestellt werden.

  • Unabhängig von den PMD-Regeln wurden die folgenden Klassen umbenannt:

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

    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 der nächsten MyCoRe-Version umgestellt werden.

  • Beim Instanziieren von konfigurierbaren Klasseninstanzen kann in einer betroffenen Klasse eine Factory-Methode definiert werden. Wenn eine solche Methode gefunden wird, wird diese Methode verwendet, um die Instanz zu erstellen, die anschlieĂźend mit aus der Konfiguration entnommenen Werten befĂĽllt wird. Bisher wurde als Factory-Methode diejenige Methode innerhalb der betroffenen Klasse verwendet, die public ist, static ist, parameterlos ist, einen passenden RĂĽckgabewert hat und deren Namen, unabhängig von der GroĂź- und Kleinschreibung das Wort instance beinhaltet. Es darf in diesem Fall keinen parameterlosen öffentlichen Konstruktor geben.

    Dieser Mechanismus wird in der nächsten MyCoRe-Version entfernt. Eine angedachte Factory-Methode muss stattdessen mit @MCRFactory gekennzeichnet werden. In diesem Fall ist der Name egal und die Methode wird einem etwaigem parameterlosen öffentlichen Konstruktor bevorzugt. In 2025.06 wird bei Verwendung des alten Mechanismus eine Warnung geloggt. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung der nächsten MyCoRe-Version umgestellt werden.

  • Beim Instanziieren von konfigurierbaren Klasseninstanzen kann ein Feld bisher mit einer Map<String, String> befĂĽllt werden (oder einer entsprechenden Methode ĂĽbergeben werden), wenn diese mit @MCRInstance("*") oder @MCRInstance("Foo.Bar.*") gekennzeichnet ist.

    Dieser Mechanismus wird in der nächsten MyCoRe-Version entfernt. Ein solches Feld (oder eine solche Methode) dann stattdessen mit @MCRRawProperties("*") oder @MCRRawProperties("Foo.Bar.*") gekennzeichnet werden. In 2025.06 wird bei Verwendung des alten Mechanismus eine Warnung geloggt. Eigener Code bleibt daher noch funktionsfähig, muss aber vor der Verwendung der nächsten MyCoRe-Version umgestellt werden.

  • Die Klasse MCRResourceException wurde entfernt. Methoden, die bisher derartige Ausnahmen geworfen haben, werfen nun MCRResourcePath.IllegalPathException; eine Subklasse von IllegalArgumentException. Einer Instanz einer solchen Ausnahme kann mit MCRResourcePath.IllegalPathException#code der Grund fĂĽr die Ausnahme entnommen werden.

  • Mit MCR-3273 wurde u.A. die verschiedenen Methoden von MCRUser zum Erstellen von Kopien (clone, getBasicCopy, getSafeCopy, getFullCopy) ĂĽberarbeitet. Enthaltenen owner werden nun nach demselben Kriterium kopiert. Eine "sichere Kopie" (u.A. ohne Zugangsinformationen) beinhaltet nicht mehr die Zugangsinformationen des besitzenden Nutzers. Die jetzt umgesetzten Regeln lassen sich am besten MCRUserCopyTest entnehmen. Eigener Code muss gegebenenfalls angepasst werden.

    Instanzen von MCRTransientUser können nun nicht mehr geklont werden. Stattdessen kann die Methode getPersistableCopy verwendet werden. Eigener Code muss gegebenenfalls angepasst werden.

- 20.06.2025