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