Hallo, wir werden im Laufe der Woche noch einen SQL Dump für das Release bereitstellen. Ich informiere sie, wenn sie es auf der releaseseite finden können. Liebe Grüße Kathrin Huber Kathrin Huber Digitale Objekte Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat 2.5 01054 Dresden Besucheradresse: Zellescher Weg 18, 01069 Dresden Tel.: +49 351 4677 242 | Fax: +49 351 4677 711 E-Mail: kathrin.huber(a)slub-dresden.de www.slub-dresden.de | www.kitodo.org/ -----Ursprüngliche Nachricht----- Von: kitodo-community-bounces(a)kitodo.org <kitodo-community-bounces(a)kitodo.org> Im Auftrag von Lutz Helm Gesendet: Mittwoch, 27. März 2019 15:05 An: kitodo-community(a)kitodo.org Betreff: Re: [Kitodo] Tomcat kann war-Datei vom letzten Beta-Release nicht bereitstellen Hallo! Folgendes Problem hatte ich auch festgestellt: org.hibernate.HibernateException: Schema-validation: missing table [client_x_listColumn] Das Schema hat sich in der beta3 gegenüber beta2 nochmal erheblich geändert. Es wäre schön, wenn dafür nochmal ein SQL-Dump bereitgestellt werden könnte. Wer nicht bis dahin warten möchte, könnte alle Migrations ab inklusive V2_66__Remove_index_column_from_client_user_and_role.sql bis inklusive V2_74__Add_repeatOnCorrection_to_task_table.sql unter /kitodo-data-management/src/main/resources/db/migration/ ausführen, siehe [1]. Das geht leider nicht über den Maven-migrate-Task des Maven-Moduls, weil der beta2-Datenbank-Dump keine history-Tabelle enthält. Wer das trotzdem über Maven machen will, könnte auf einer leeren Datenbank V1_0 bis V2_65 einspielen, dann alle noch notwendigen Inserts (jedoch keine DROP / CREATE TABLE) aus dem beta2-SQL-Dump ausführen (einige sind überflüssig / können wegen Duplikaten nicht ausgeführt werden), und danach die Migrations von V2_66 bis V2_74. Nur die Migrations ausführen ohne Inserts aus dem beta2-Dump führt zu fehlenden Testbenutzern. Wer auf dem beta1-SQL-Dump aufsetzen möchte, benötigt entsprechend mehr Migrations. Einfacher wäre, wie gesagt, ein frischer SQL-Dump. Viele Grüße Lutz Helm [1] https://github.com/kitodo/kitodo-production/tree/master/Kitodo-DataManageme… Am 27.03.19 um 14:39 schrieb Rainer.Lunge(a)web.de: -- Lutz Helm Bereich Digitale Dienste AG Anwendungsentwicklung Universitätsbibliothek Leipzig Beethovenstraße 6, 04107 Leipzig T: +49 341 97 30566 helm(a)ub.uni-leipzig.de https://www.ub.uni-leipzig.de/ _______________________________________________ Kitodo-Community mailing list Kitodo-Community(a)kitodo.org https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community

Liebe Kollegen, auf der Releaseseite<https://github.com/kitodo/kitodo-production/releases/tag/ki… finden sie nun den SQL Dump passend zum beta-3 Release. Es steht ihnen natürlich jederzeit frei die Flywaymigration auf ihrer Datenbank durchzuführen. Diese funktioniert auf einer leeren Datenbank (Ab Migrationsscript V1_0__...) oder auf einer Kitodo Datenbank der Version 2.x (Ab Migrationsscript V2_0__...) Flywaymigrationen für Stände von Betareleases sind nicht vorgesehen. Für die Migrationsszenarien von produktiven Kitodo Datenbanken beschäftigen sich aktuell Entwickler im Thema „Kitodo-Migration“, wie werden hier noch einen Workflow bereitstellen um sicher zu stellen, dass die Datenbanken korrekt migriert werden. Beispieldaten finden sie in der Datei ..\Kitodo\setup\default.sql. Diese können sie auf die Datenbank im alten Format (bzw. nach dem Migrationsscript V1_0) aufspielen. Ich wünsche viel Erfolg beim Testen. Liebe Grüße Kathrin Huber Kathrin Huber Digitale Objekte Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat 2.5 01054 Dresden Besucheradresse: Zellescher Weg 18, 01069 Dresden Tel.: +49 351 4677 242 | Fax: +49 351 4677 711 E-Mail: kathrin.huber(a)slub-dresden.de www.slub-dresden.de<http://www.slub-dresden.de/> <mailto:jens.bemme@slub-dresden.de> | www.kitodo.org/ Von: kitodo-community-bounces(a)kitodo.org &lt;kitodo-community-bounces(a)kitodo.org&gt; Im Auftrag von Richter, Michael Gesendet: Mittwoch, 27. März 2019 16:36 An: kitodo-community(a)kitodo.org Betreff: Re: [Kitodo] Tomcat kann war-Datei vom letzten Beta-Release nicht bereitstellen Hallo Frau Huber, da Sie ja in Kitodo Production Flyway einsetzen, wäre es nicht besser die Anleitung so anzupassen, dass man die Flyway-Migrationen einfach ausführt und ggf. Initial-Daten beipackt? So habe ich das Problem behoben - also ähnlich, wie es Herr Helm beschrieben hat. Das würde in Zukunft die Migration auf neuere Versionen doch erleichtern, denke ich. Gruß -- Michael Richter Abt. Online-Dienste und IT-Entwicklung Technische Universität Berlin Universitätsbibliothek Fasanenstraße 88 10623 Berlin Telefon: +49 (0)30 314-76097 m.richter@tu-berlin.de<mailto:m.richter@tu-berlin.de> www.tu-berlin.de<http://www.tu-berlin.de> Am Mittwoch, den 27.03.2019, 14:58 +0000 schrieb Huber, Kathrin: Hallo, wir werden im Laufe der Woche noch einen SQL Dump für das Release bereitstellen. Ich informiere sie, wenn sie es auf der releaseseite finden können. Liebe Grüße Kathrin Huber Kathrin Huber Digitale Objekte Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat 2.5 01054 Dresden Besucheradresse: Zellescher Weg 18, 01069 Dresden Tel.: +49 351 4677 242 | Fax: +49 351 4677 711 E-Mail: kathrin.huber@slub-dresden.de<mailto:kathrin.huber@slub-dresden.de> www.slub-dresden.de<http://www.slub-dresden.de> | www.kitodo.org/<http://www.kitodo.org/> -----Ursprüngliche Nachricht----- Von: kitodo-community-bounces@kitodo.org<mailto:kitodo-community-bounces@kitodo.org> <kitodo-community-bounces@kitodo.org<mailto:kitodo-community-bounces@kitodo.org>> Im Auftrag von Lutz Helm Gesendet: Mittwoch, 27. März 2019 15:05 An: kitodo-community@kitodo.org<mailto:kitodo-community@kitodo.org> Betreff: Re: [Kitodo] Tomcat kann war-Datei vom letzten Beta-Release nicht bereitstellen Hallo! Folgendes Problem hatte ich auch festgestellt: org.hibernate.HibernateException: Schema-validation: missing table [client_x_listColumn] Das Schema hat sich in der beta3 gegenüber beta2 nochmal erheblich geändert. Es wäre schön, wenn dafür nochmal ein SQL-Dump bereitgestellt werden könnte. Wer nicht bis dahin warten möchte, könnte alle Migrations ab inklusive V2_66__Remove_index_column_from_client_user_and_role.sql bis inklusive V2_74__Add_repeatOnCorrection_to_task_table.sql unter /kitodo-data-management/src/main/resources/db/migration/ ausführen, siehe [1]. Das geht leider nicht über den Maven-migrate-Task des Maven-Moduls, weil der beta2-Datenbank-Dump keine history-Tabelle enthält. Wer das trotzdem über Maven machen will, könnte auf einer leeren Datenbank V1_0 bis V2_65 einspielen, dann alle noch notwendigen Inserts (jedoch keine DROP / CREATE TABLE) aus dem beta2-SQL-Dump ausführen (einige sind überflüssig / können wegen Duplikaten nicht ausgeführt werden), und danach die Migrations von V2_66 bis V2_74. Nur die Migrations ausführen ohne Inserts aus dem beta2-Dump führt zu fehlenden Testbenutzern. Wer auf dem beta1-SQL-Dump aufsetzen möchte, benötigt entsprechend mehr Migrations. Einfacher wäre, wie gesagt, ein frischer SQL-Dump. Viele Grüße Lutz Helm [1] https://github.com/kitodo/kitodo-production/tree/master/Kitodo-DataManageme… Am 27.03.19 um 14:39 schrieb Rainer.Lunge@web.de<mailto:Rainer.Lunge@web.de>: Hallo und vielen Dank an Frau Huber und Herrn Richter für die Rückmeldungen. Nach einem kurzen Test mit der neuen war-Datei, lässt sich diese immer noch nicht fehlerfrei vom Tomcat bereitstellen. Das Log sieht dabei wie folgt aus: cataline.out <https://pastebin.com/VfNk7BME> Was genau die Fehler beim Bereitstellen der aktuellen war-Datei verursacht habe ich bis jetzt noch nicht genauer untersucht. Bezüglich der Skripte bin ich mir nicht mehr 100%ig sich ob ich diese damals aus dem master hatte oder nicht. Bisweilen sind die Skriptdateien vom beta2-Release jedoch alle im Windowszeichensatz formatiert. kitodo-production-3.0.0-beta.2-config.zip <https://github.com/kitodo/kitodo-production/releases/download/kitodo-production-3.0.0-beta.2/kitodo-production-3.0.0-beta.2-config.zip> Zusätzlich sind die script_createSymlink.sh und die script_createSymlink.bat vom Inhalt identisch, heißt im shell-Skript werden batch Befehle verwendet. Viele Grüße Rainer Lunge *Gesendet:* Mittwoch, 27. März 2019 um 13:04 Uhr *Von:* "Huber, Kathrin" <Kathrin.Huber@slub-dresden.de<mailto:Kathrin.Huber@slub-dresden.de>> *An:* "kitodo-community@kitodo.org<mailto:kitodo-community@kitodo.org>" <kitodo-community@kitodo.org<mailto:kitodo-community@kitodo.org>> *Betreff:* Re: [Kitodo] Tomcat kann war-Datei vom letzten Beta-Release nicht bereitstellen Liebe Kollegen und Kolleginnen, vielen Dank für die Hinweise. Die war-Datei wurde leider mit dem falschen Profil und dadurch mit falschen Konfigurationen gebaut. Ich hab dies sofort behoben und eine neue war ans Release angehängt. Bitte entschuldigen sie die Unannehmlichkeiten! Die Pfade sollte nun passen. Ich bitte für weitere Tests die neue war von der Releaseseite <https://github.com/kitodo/kitodo-production/releases/tag/kitodo-production-3.0.0-beta.3> zu nutzen. Zu der Frage mit den Shellscripten. Diese werden in der war nicht ausgeliefert und sollten im github mit dem richtigen Linuxzeichensatz vorliegen. Haben sie diese aus einer anderen Quelle? Mit freundlichen Grüßen Kathrin Huber Kathrin Huber Digitale Objekte Sächsische Landesbibliothek – Staats- und Universitätsbibliothek Dresden (SLUB) Abteilung IT, Referat 2.5 01054 Dresden Besucheradresse: Zellescher Weg 18, 01069 Dresden Tel.: +49 351 4677 242 | Fax: +49 351 4677 711 E-Mail: kathrin.huber@slub-dresden.de<mailto:kathrin.huber@slub-dresden.de> www.slub-dresden.de<http://www.slub-dresden.de> <http://www.slub-dresden.de/><mailto:jens.bemme@slub-dresden.de<http://www.slub-dresden.de/%3e%3cmailto:jens.bemme@slub-dresden.de>>| www.kitodo.org/<http://www.kitodo.org/> <http://www.kitodo.org/> *Von:*kitodo-community-bounces@kitodo.org<mailto:*kitodo-community-bounces@kitodo.org> <kitodo-community-bounces@kitodo.org<mailto:kitodo-community-bounces@kitodo.org>> *Im Auftrag von *Richter, Michael *Gesendet:* Montag, 25. März 2019 14:59 *An:* kitodo-community@kitodo.org<mailto:kitodo-community@kitodo.org> *Betreff:* Re: [Kitodo] Tomcat kann war-Datei vom letzten Beta-Release nicht bereitstellen Hallo Herr Lunge, ich bin über das selbe (und weitere) Probleme gestolpert. Ich habe den Pfad in diesen beiden Dateien angepasst, wenn ich mich recht erinnere: - ./WEB-INF/classes/log4j.properties - ./WEB-INF/classes/log4j2.xml Die Dateien finden sich im entpackten JAR, also im webapps/kitodo3beta/... von Tomcat. Gruß -- Michael Richter Abt. Online-Dienste und IT-Entwicklung Technische Universität Berlin Universitätsbibliothek Fasanenstraße 88 10623 Berlin Telefon: +49 (0)30 314-76097 m.richter@tu-berlin.de<mailto:m.richter@tu-berlin.de> <mailto:m.richter@tu-berlin.de<mailto:m.richter@tu-berlin.de>> www.tu-berlin.de<http://www.tu-berlin.de> <http://www.tu-berlin.de> Am Montag, den 25.03.2019, 14:49 +0100 schrieb Rainer.Lunge@web.de<mailto:Rainer.Lunge@web.de> <mailto:Rainer.Lunge@web.de<mailto:Rainer.Lunge@web.de>>: Hallo zusammen, mein zugrundeliegendes Setting orientiert sich strikt nach folgender Anleitung. https://github.com/kitodo/kitodo-production/wiki/Installationsanleitung-f%C… Den Beta1-Release konnte man damit problemlos hosten. Dabei möchte ich als Anmerkung nur kurz loswerden, dass bei der Entwicklung darauf geachtet werden sollte, Unix- u. Windowszeichensatz nicht zu vermischen. Die Shellskripte werden unter Linux nicht ausgeführt wenn ein Windowszeichensatz vorliegt. Die Fehlerquelle dafür zu finden hat einiges an Zeit verschlungen. Aber nun zum eigentlichem Thema, beim gleichen Setting produziert das Einbinden des Beta3-Releases eine Reihe an Fehlermeldungen. catalina.out - Log <https://pastebin.com/i6TGfw0F> Ursache dafür ist unteranderem wieder keine klare Trennung zwischen Linux und Windows, da Windowspfade referenziert werden die womöglich hardcoded im Quellcode implementiert sind. Beispiele: ERROR FileManager (C:/dev//kitodo.log) java.io.FileNotFoundException:.... ERROR FileManager (C:/dev//hibernate.log) java.io.FileNotFoundException:... ERROR FileManager (C:/dev//myfaces.log) java.io.FileNotFoundException:.... Die URL der Webapp lässt sich anschließend auch nicht aufrufen, es kommt weder zu einem timeout noch einer 404, nach einigem Laden passiert einfach nichts. Meine Frage ist nun, gibt es eine Möglichkeit den besagten Fehler zu korrigieren, ohne dass man sich seinen eigenen Build kompilieren muss oder liegt der Fehler eventuell an ganz anderer Stelle, da es prinzipiell ja auch nur log-Dateien sind? Mit freundlichen Grüßen Rainer Lunge _______________________________________________ Kitodo-Community mailing list Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org> <mailto:Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org>> https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community _______________________________________________ Kitodo-Community mailing list Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org> https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community _______________________________________________ Kitodo-Community mailing list Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org> https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community -- Lutz Helm Bereich Digitale Dienste AG Anwendungsentwicklung Universitätsbibliothek Leipzig Beethovenstraße 6, 04107 Leipzig T: +49 341 97 30566 helm@ub.uni-leipzig.de<mailto:helm@ub.uni-leipzig.de> https://www.ub.uni-leipzig.de/ _______________________________________________ Kitodo-Community mailing list Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org> https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community _______________________________________________ Kitodo-Community mailing list Kitodo-Community@kitodo.org<mailto:Kitodo-Community@kitodo.org> https://maillist.slub-dresden.de/cgi-bin/mailman/listinfo/kitodo-community