[ MyCoRe Home ] [ MyCoRe/Dokumentation ] [ Migration ]
Migration von Version 1.3 nach 2.0
Änderungen am eigenen Source Code
Migration des User-Systems
Alle Klassen des User-Systems sind jetzt nicht mehr in org.mycore.user2. Das Package wurde in org.mycore.user umbenannt. Klassen in der eigenen Applikation, welche die angeführten Manager verwenden, müssen in den import-Statements angepasst werden.
Für die automatische Migration wurde das Kommando migrate users für die MyCoRe-Kommandozeile erstellt. Mit diesem Kommando werden alle Nutzer und Gruppen exportiert, die Tabellen gelöscht und mit den Fremdschlüsselbedingungen neu erstellt und anschließend alle Nutzer und Gruppen wieder importiert.
WICHTIG: Standardmäßig ist der neue Super-Nutzer "administrator" und nicht mehr "root". Das sich ein Super-Nutzer (seit Version 2.0) in den Rechten selbst einschränken kann, ist darauf zu achten, dass der (ggf. neue) Super-Nutzer die Rechte "modify-user" und "modify-group" hat, da sonst bestimmte Operationen fehl schlagen würden. Falls dem Super-Nutzer diese Rechte entzogen sind, werden die entsprechenden Rechte automatisch bei migrate users gelöscht, um einen fehlerfreien Durchlauf zu gewährleisten.
Weil die Datenbanktabellen der Nutzerverwaltung jetzt per Fremdschlüsselbeziehung miteinander verknüpft sind, müssen die alten Nutzerdaten bereinigt werden, sollte das Hinzufügen der Fremdschlüssel scheitern:
ALTER TABLE mcrusers DROP PRIMARY KEY, add PRIMARY KEY (uid); UPDATE MCRGROUPADMINS SET userid = 'root' WHERE userid = ''; UPDATE MCRGROUPADMINS SET groupid = 'admingroup' WHERE groupid = '' AND userid != 'root'; DELETE FROM mcrgroupadmins WHERE groupid = '';
admingroup und root sind die jeweilige Supergruppe/Supernutzer, wie sie in mycore.properties.private eingetragen sind.
Migration der Klassen des XML- und LinkTabelManagers
Da diese beiden Manager mit ihren dazugehörigen Interfaces für die Stores unabhängig von der Ausprägung des Objektdatenmodells sind, wurden die zugehörigen Klassen von org.mycore.datamodel.metadata nach org.mycore.datamodel.common verschoben. Im common Package sollen zukünfig alle Klassen stehen, die unabhängig für alle Datenmodellkomponenten verfügbar sein sollen. Dazu gehört auch die Klasse MCRActiveLinkException.
Klassen in der eigenen Applikation, welche die angeführten Manager verwenden, müssen in den import-Statements angepasst werden.
Migration des Klassifikationssystems
Die Klassen des packages org.mycore.datamodel.classification.query wurden nach org.mycore.datamodel.classification verschoben und ersetzten jetzt die alten Klassifikations-Klassen. Es hat sich die interne Darstellung jedoch NICHT das Datenmodell komplett geändert. Hinzugekommen ist optional ein service-Block analog in Form von MCRObjectService. Damit können Klassifikationen ab sofort mit ACLs geschützt werden. Die Stores für den MCRAccessManager und MCRXMLTableManager werden ab sofort über den MCREventHandler angesprochen. In der Konfiguration mycore.properties sind dazu folgende Einträge vorzunehmen:
MCR.EventHandler.MCRClassification.1.Class=org.mycore.access.MCRAccessEventHandler MCR.EventHandler.MCRClassification.2.Class=org.mycore.datamodel.common.MCRXMLTableEventHandler
Ggf. müssen die API Zugriffe in den Souce Codes der Anwendungen angepasst werden. MCRClassification enthält nicht mehr so viele statische Methoden. Diese sind jetzt durch den Zugriff auf die entsprechenden Manager (Access, XMLTable, Classification) zu ersetzten.
Migration der Editordefinitionen
Achtung
Der Editor in MyCoRe 2.0 verwendet Namespaces. Das bedeutet, dass für Elemente der Typen MCRMetaLink, MCRMetaLinkID, ... das Präfix xlink in die Editordefinition aufgenommen werden muss. Sonst werden die Informationen beim Laden der Daten nicht in den Eingabefeldern angezeigt und folglich beim Speichern gelöscht.
<panel id="Dhomepages">
<hidden var="metadata/homepages/@class" default="MCRMetaLink" />
<cell col="1" row="1" anchor="NORTHWEST" var="metadata/homepages/homepage" >
<panel>
<hidden var="@xlink:type" default="locator" />
<cell col="1" row="1" anchor="NORTHWEST" ref="TFzeile1024" var="@xlink:href" />
<cell col="2" row="1" anchor="NORTHWEST" >
<text class="editorHint" i18n="Editor.Label.URLLink" />
</cell>
<cell col="1" row="2" anchor="NORTHWEST" ref="TFzeile1024" var="@xlink:title" />
<cell col="2" row="2" anchor="NORTHWEST" >
<text class="editorHint" i18n="Editor.Label.linktitel" />
</cell>
</panel>
</cell>
</panel>Analog dazu sollte bei MCRMetaLangText u.ä. das Attribut @lang in @xml:lang umbenannt werden.
Änderungen an der Konfiguration der eigenen Anwendung
Änderung der Properties
Mit dem neuen Release werden die Bezeichnungen der Properties weitgehend vereinheitlicht. Die aktuelle Notation ist MCR.Xxx.Yyy wobei Xxx für den Komponentenbezeichner steht. Dieser beginnt i.d.R. mit einem Großbuchstaben, Ausnahmen sind URI usw. Yyy ist ein beliebiger String, dessen Elemente mit einem . getrennt sind. Jedes Element sollte mit einem Großbuchstaben beginnen. Wird im property-Namen der MCRObjectTyp mit codiert, so sind dafür natürlich Kleinbauchstaben zu verwenden. Es gibt eine Zuweisungsliste für alte property-Namen zu den aktuellen Bezeichnern. MyCoRe protokolliert alle Zugriffe auf nicht mehr aktuelle properties im Log-File. Die Liste wirkt aber nur bei der Verwendung des Java-Codes. Für die Nutzung von ANT sind eigenhändige Korrekturen in den XML-Dateien vorzunehmen. Es ist ratsam, die eigene Anwendung im Lauf der nächsten Zeit umzustellen, da die Zuweisungsliste nur eine vorübergehende Lösung darstellt.
Migration der Suchmasken
Damit die Suchmasken wieder laufen sind folgende, kleinere Anpassungen vorzunehmen:
TextCounter
Die Umbenennung von MCR.URIResolver.Classification.Format.TextCounter erfordert eine Anpassung von Zeilen der Art:
<include uri="classification:editor[textcounter]:2:children:DocPortal_class_00000007" />
nach:
<include uri="classification:editor[TextCounter]:2:children:DocPortal_class_00000007" />
<source>
Weiterhin gab es Aenderungen bei Schreibweise und Attributmenge des source-Elementes. Hier ist folgende Anpassung vorzunehmen:
<source url="request:servlets/MCRSearchServlet?mode=load&id=[ID]" token="[ID]" />
aendern in:
<source uri="request:servlets/MCRSearchServlet?mode=load&id={id}" />(Man beachte auch, dass es nun 'uri' anstatt 'url' ist!)
<section lang="all">
Ein zusätzliches Feature ist die neue Möglichkeit, sprachunabhängige Abschnitte anzulegen, die dann entweder vor oder nach den sprachabhängigen Abschnitten dargestellt werden. Dadurch kann man die Suchmasken an einer Stelle einbinden. Siehe dazu die Beispiele im aktuellen DocPortal, z.B. editor_form_search-simpledocument.xml (unter docportal/webpages).
Migration der WCMS-Nutzer
Mit dem Snapshot 20070824 wurde die propriotäre Nutzerverwaltung des WCMS-Modules durch die MyCoRe-Eigene ersetzt. Benutzer des WCMS authentifizieren sich künftig wie alle anderen Nutzer am MyCoRe-System. Grundsätzlich wird der Zugang zum WCMS jetzt mit dem MyCoRe-ACL-System realisiert.
Die Einträge in der alten WCMSUserDB.xml müssen dazu in Nutzer, Gruppen und ACL's umgewandelt werden. Es gibt mit dem Snapshot ein Migrations-Tool, das die nötigen Schritte automatisch durchführt. Folgende Schritte migrieren die bisherige WCMS-Nutzerverwaltung in das aktuelle MyCoRe-System.
in ihrer MyCoRe-Anwendung, CLI:
- ant jar create.scripts
Überprüfen sie alle registrierten Nutzer in ihrer WCMSUserDB.xml, ob diese so migriert werden sollen (unbekannte Nutzer werden neu angelegt, Nutzer, die es schon im Mycore-System gibt werden benutzt und nicht neu erzeugt)
Kopieren sie ihre alte WCMSUserDB.xml an die Stelle, die sie in mycore.properties.wcms unter dem Eintrag MCR.WCMS.wcmsUserDBFile konfiguriert haben
Kopieren sie ihre alte navigation.xml an die Stelle, die sie in mycore.properties.wcms unter dem Eintrag MCR.navigationFile konfiguriert haben
Starten sie das Migrations-Tool durch
- CLI starten
- login root
- simulate migrate wcms-users (was würde passieren, simuliert die Migration, keine Daten werden in der DB angelegt)
- ODER
- migrate wcms-users (führt die Migration aus)
Jetzt sollten die alten Nutzer der WCMSUserDB.xml in Nutzer, Gruppen und ACL's übertragen worden sein und voll nutzbar sein.
Hinweis: Nutzer, die neu angelegt worden sind, haben als Passwort den Anmeldenamen und sollten geändert werden.
Test der Migration von Version 1.3 nach 2.0
Um zu überprüfen, ob die Migration erfolgreich war, können die Änderungen anhand dieses Dokumentes verglichen werden: Aenderung_Tabellenstruktur_Snapshot_Aug2007.pdf