2023.06

Migration MyCoRe LTS 2022.06 nach 2023.06

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

Systemanforderungen MyCoRe LTS 2023.06

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

Betriebssystem

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

Open SuSE Leap 15.4 oder höher
SuSE SLES 15.4 oder höher
Ubuntu 20.04 LTS
CentOS 8
RHEL 8
Windows 10 für Test- und Entwicklungssysteme

Standardsoftware

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

Java 17 (OpenJDK) (muss ggf. extern nachinstalliert werden, Java 21 als Laufzeitumgebung funktioniert ebenfalls)
Tomcat 10.1.x bzw. Jetty 11.x (alternativ ein System mit Unterstützung von Servlet-6.0 und JakartaEE)
SOLR 8.11.2 oder höher
eine hibernate-fähige relationale Datenbank wie PostgreSQL 10 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

ToDo: ergänzen

aus dem Code entfernt

ToDo: ergänzen

Migrationsschritte

Aktuelle Versionsnummer

Viel Anwender nutzen nicht die über Maven Central bereitgestellten Releases sondern möchten von den eingearbeiteten Bugfixes der Entwickler profitieren. Hierfür muss das Nexus Repository mit den bereitgestellten SNAPSHOTS eingebunden werden. Für Release 2023 kann folgende Version genutzt werden:

1
2
3
4
5


 <dependency>
   <groupId>org.mycore</groupId>
   <artifactId>...</artifactId>
   <version>2023.06.1-SNAPSHOT</version>
 </dependency>

Job-Konzeptes

Das Job-Konzept wurde komplett überarbeitet. Mit dem aktuellen LTS ist die folgende Ergänzung in der persistence.xml erforderlich.

1

 <mapping-file>META-INF/mycore-jobqueue-mappings.xml</mapping-file>

Mit dem CLI-Kommando reload mappings in jpa configuration file werden die Mapping-Einträge aktualisiert und dieses und ggf. weitere Mappings automatisch der Datei persistence.xml hinzugefügt. Nicht mehr benötigte Mappings werden mit dem Kommando automatisch entfernt.

XSLT-3

Mit Release 2023.06 ist Saxon der Standard-Transformer. Somit werden für Solr-, OAI- und Layout-Transformationen der Saxon-Parser benutzt. Alle Saxon- kompatiblen Stylesheets (egal ob XSLT Version 1, 2 oder 3) stehen im MyCoRe-Kern im Verzeichnis xslt zur Verfügung. Für alle MyCoRe-Komponenten bis auf mycore-mods wurden entsprechende Stylesheets bereitgestellt. Damit diese in den Anwendungen eingebunden werden, musste die Konfiguration entsprechend angepasst werden. Beispielsweise ist in MyCoRe nun das folgende Property gesetzt: MCR.Layout.Transformer.Factory.XSLFolder=xslt. Wenn man in der eigenen Anwendung noch Xalan für das Layout und die entsprechenden Stylesheets aus dem xsl-Verzeichnis nutzen möchte, muss dieses Property angepasst und auf MCR.Layout.Transformer.Factory.XSLFolder=xsl gesetzt werden.

So ist es möglich in der eigenen Anwendung Schritt für Schritt die Stylesheets umzustellen. Als Vorlage kann der entsprechende Commit in MIR helfen. Als Hilfestellung bei der Migration eigener Stylesheets kann die Dokumentation zur Nutzung von XSLT3 herangezogen werden. In der Präsentation [ToDo: Vorträge von Micha und Sebastian].

Erweiterung von MCRTranslate.translate() um die Möglichkeit einer Lokalisationsangabe

Damit eine "Locale" angegeben werden kann, mussten die Methoden translate(String, Locale) und translate (String, Objects ....) umgestellt werden. Dies erfordert ggf. eine Migration lokaler Javaklassen, die diese Methoden nutzen. Alle MCRTranslation.translate() mit locale Parameter müssen nach MCRTranslation.translateToLocale() umbenannt werden. [MCR-2978]

Unterstützung für HSQLDB und c3p0 entfällt, H2 muss migriert werden

Migrationsanleitung zur H2 befindet sich im Ticket MCR-2647.

JPA-Update auf 3.1

Das JPA-Update auf 3.1 bringt eine Anpassung der Datenbank mit sich (vgl. Commit).
Diese erfordert eine Änderung des Datentyps der Spalte eventtype der Tabelle mcrmetahistory von varchar(1) auf char(1).
Es sollte geprüft werden, ob die Aktualisierung durch JPA automatisch vorgenommen wurde. Falls in der JPA-Konfiguration automatische Schema-Updates abgeschaltet sind, kann das Update mit folgendem Kommando durchgeführt werden:
alter table mcrmetahistory alter COLUMN eventtype type char(1);

Privileg `create-derivate` prüfen und ggf. ergänzen

Nach Überarbeitung des Uploads wird nun konsequenter Weise auch das Privileg create_derivate gecheckt. In den meisten Altanwendungen wurde dieses nicht angelegt, sondern die Rechte zum Erstellen von Derivaten nur von den Objekttyp-Create-Privilegien abgeleitet.
Jetzt muss das Privileg create_derivate explizit gesetzt werden, um weiterhin das Anlegen von Derivaten zu erlauben.