Februar
Goobi viewer Digest für Februar 2022
- Anzeige eines Disclaimers für Werke
- Kommentarsichten
- Upload von Datensätzen
Dieser Digest erscheint zu einer Zeit, in der in Europa ein Krieg ausgebrochen ist. Uns erreichen entsetzliche Nachrichten aus der Ukraine.
Wir stehen in Solidarität mit allen Menschen, die von diesem schrecklichen Krieg betroffen sind.
Der Goobi viewer kann jetzt einen Cookie Banner anzeigen. Dieser wird im Backend konfiguriert. Die Funktionalität kann dort ein- oder ausgeschaltet und der Text für den Banner verwaltet werden. Außerdem steht eine Liste von CMS-Seiten zur Verfügung, auf denen der Banner nicht angezeigt werden soll. Das kann zum Beispiel für ein Impressum, eine Datenschutz- oder eine Cookie-Richtlinien-Seite notwendig sein. Weiter ist es Möglich die Zustimmung von Nutzern zurückzusetzen, zum Beispiel wenn es bei dem Text eine Änderung gab und eine erneute Zustimmung notwendig ist.
Der Cookie Banner ist mit der Matomo Tracking Funktionalität verknüpft. Sind beide aktiv, findet ein Tracking erst dann statt, wenn der im Banner angezeigte Text akzeptiert wurde. Wird der Text nicht akzeptiert, dann wird das Tracking unterbunden.
Die Information über Zustimmung oder Ablehnung des Textes wird im Local Storage des Browsers gespeichert. Damit ist sie über die Session hinaus gültig und dem Text muss nur einmalig zugestimmt werden.
Cookie Banner im Frontend
Verwalten des Cookie Banner Texts
Auswahl von vom Banner ausgenommenen CMS-Seiten
Im Goobi viewer haben wir seit vielen Jahren ein sehr simples aber effektives Prinzip in der Entwicklung:
Bugfix geht vor Feature
Das bedeutet konkret, dass wenn wir einen Bug in der Software sehen oder gemeldet bekommen, dieser behoben wird bevor wir mit der Entwicklung von neuen Features fortfahren. Die Bugfixes fließen dann in die aktuelle Codebasis ein und - sofern möglich und nötig - portieren wir den konkreten Fix auch in frühere Versionen zurück.
In der Praxis sind das oft nur Fragen von einer halben Stunde oder einer weniger Zeilen Quelltext. Mehr braucht es häufig nicht und man kann die Arbeiten gut am Anfang oder Ende des Tage einplanen.
In diesem Monat hatten wir einen Fehler anderer Güte. Dabei verlor der Goobi viewer quasi aus heiterem Himmel seine Datenbankanbindung. Von jetzt auf gleich wurde beim Aufruf einer Seite die Meldung angezeigt "Connection has already been closed". Das Einzige was dann geholfen hat war den Tomcat Prozess komplett neu zu starten.
Uns alle hat dieser Fehler vor ein Rätsel gestellt, denn der Goobi viewer verwaltet die Datenbankanbindung gar nicht selbst sondern der Tomcat übernimmt das und reicht sie nur weiter. Der wiederum hatte jederzeit genügend offene und nicht genutzte Verbindungen, auch, wenn der Goobi viewer die Fehlermeldung gab waren die Verbindungen noch aktiv. Erschwerend kam hinzu, dass wir absolut keine Möglichkeit hatten den Fehler selbst bei uns zu nachzustellen oder zu provozieren. Wir konnten nur auf installierten Live-Systemen das Symptom sehen. Ein Nachstellen in der Entwicklungsumgebung war hingegen nicht möglich. Das Symptom trat manchmal fünf Minuten nach dem Start des Tomcats auf und dann wieder erst nach zwei Tagen. Ohne für uns erkennbare Unterschiede in der Nutzung...
Diverse Kollegen haben sich dann auf die Suche begeben. Zuerst im Quelltext ob irgendwelche Verbindungen versehentlich geschlossen werden. Auf dieser Suche wurden zwar Bugs gefunden und behoben, aber keine die konkret damit in Verbindung standen. Die Analyse wurde dann ausgeweitet auf andere Teile in der Kette: Tritt der Fehler nur mit MariaDB oder auch mit MySQL auf? Tritt der Fehler bei älteren oder neueren Tomcat Versionen nicht mehr auf? Tritt der Fehler bei einer Änderung des Connectors auf, mit dem der Tomcat sich zur Datenbank verbindet? Was passiert, wenn wir die (seit Jahren unveränderten) Parameter ändern, mit denen der Tomcat eine Verbindung zur Datenbank aufbaut? Alle Ansätze wurden geprüft und bei jeder Änderung mussten wir auf den installierten Systemen gucken ob diese zum Erfolg führen. Leider war das Ergebnis immer wieder aufs neue ernüchternd: Alle Maßnahmen führten zu keiner Änderung. Wir konnten also ab einem gewissen Zeitpunkt mit recht hoher Gewissheit sagen, dass kein Fehler im Code die Verbindung schließt und auch das Setup und die Komponenten dazwischen nicht Ursächlich sind. Der Fehler existierte aber weiterhin.
Inzwischen hatten wir ein Logging aktiviert, das zu mehreren GB großen Logdateien pro Stunde führte. Damit wurde wirklich alles was der Goobi viewer mit der Datenbank machte geloggt. Hier ein Beispiel für das Logging einer einfachen SQL Abfrage:
[EL Finer]: connection: 2022-02-24 05:01:56.878--ServerSession(1137386215)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--client acquired: 33039885
[EL Finer]: transaction: 2022-02-24 05:01:56.878--ClientSession(33039885)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--acquire unit of work: 964015310
[EL Finest]: query: 2022-02-24 05:01:56.879--UnitOfWork(964015310)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--Execute query ReadAllQuery(referenceClass=CMSStaticPage sql="SELECT static_page_id, cms_page_Id, static_page_name FROM cms_static_pages WHERE (cms_page_Id = ?)")
[EL Finest]: connection: 2022-02-24 05:01:56.879--ServerSession(1137386215)--Connection(1350487645)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--Connection acquired from connection pool [read].
[EL Finest]: connection: 2022-02-24 05:01:56.879--ServerSession(1137386215)--Connection(1350487645)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--reconnecting to external connection pool
[EL Fine]: sql: 2022-02-24 05:01:56.879--ServerSession(1137386215)--Connection(2077776754)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--SELECT static_page_id, cms_page_Id, static_page_name FROM cms_static_pages WHERE (cms_page_Id = ?)
bind => [60]
[EL Finest]: connection: 2022-02-24 05:01:56.879--ServerSession(1137386215)--Connection(1350487645)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--Connection released to connection pool [read].
[EL Finer]: transaction: 2022-02-24 05:01:56.879--UnitOfWork(964015310)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--release unit of work
[EL Finer]: connection: 2022-02-24 05:01:56.879--ClientSession(33039885)--Thread(Thread[ajp-nio-0:0:0:0:0:0:0:0-8009-exec-1,5,main])--client released
Nachdem mehrere Kollegen über mehrere Tage rhythmisch auf diese wachsenden Logfiles gestarrt haben wurden neue Fragen formuliert und recherchiert. Am Dienstag Morgen gab es dann einen neuen Ansatz: Muss die Art- und Weise der Implementierung für jede einzelne Datenbankanbindung vielleicht anders sein? Diese existiert zwar schon immer auf genau diese Art- und Weise, aber vielleicht entspricht sie nicht dem Best-Practice? Zumindest gab es nach dem Lesen von Dokumentationen und Tutorials dazu neue Ideen.
Nach kurzer Diskussion haben wir uns dann dazu entschlossen diesen Weg zu gehen. Mehrere Kollegen waren inzwischen davon überzeugt, dass eine solche Änderung auf jeden Fall eine Verbesserung des Codes darstellt, auch wenn nicht 100%tig gesagt werden kann ob die bisherige Implementierung "falsch".
Viele viele Arbeitsstunden und mehrere tausend veränderter Codezeilen später war es dann soweit und wir konnten einen -SNAPSHOT auf den Systemen prüfen die verlässlich weiterhin in nicht definierbaren Abständen zufällig die Anbindung verloren. Ab da hieß es warten und hoffen...
Am Ende stellte sich genau diese Änderung dann als Lösung herausgestellt. Alle Systeme auf denen wir die -SNAPSHOT Version installiert haben sind haben die Anbindung seitdem nicht mehr verloren. Die Graphen im Monitoring sind dabei komplett unverändert.
Es war nicht immer leicht dem Prinzip "Bugfix geht vor Feature" im vergangenen Monat treu zu bleiben. Unsere Releaseplanung und Roadmap verschiebt sich dadurch signifikant, denn wenn wir jetzt am Ende die Zeiten aller beteiligter Kollegen zusammenrechnen die an dem Problem gearbeitet haben, dann ist das fast ein kompletter Arbeitsmonat Entwicklungszeit.
Es können jetzt CMS-Seiten als Startseite für ein Werk festgelegt werden. Dadurch ist es möglich beim Öffnen von Werken über den RSS-Feed, die Suchtrefferliste oder verschiedene Resolver direkt auf eine CMS-Seite zu leiten, die weitere Informationen zu dem Werk enthält.
Diese Funktionalität steht zur Verfügung, wenn eine CMS-Seite die Option "Verknüpftes Werk" zusammen mit der Option "Als Standardansicht für verknüpftes Werk verwenden" aktiviert hat.
Bisher wurden die Werte in den Facetten immer übersetzt. Das ist zum Beispiel notwendig um nicht den internen Wert "lat", sondern dessen Übersetzung "Latein" anzuzeigen.
Es gibt aber auch Fälle, in denen das Verhalten nicht gewünscht ist. Zum Beispiel, wenn die verwendeten Schlagworte in englischer Sprache vorliegen und auch als solche sichtbar sein sollen. Dann würde der Werte "work" als "Werk" übersetzt werden, obwohl inhaltlich "Arbeit" gemeint ist.
Aus diesem Grund gibt es jetzt einen neuen Schalter in der Konfigurationsdatei, bei dem die Übersetzung von Werten in ausgewählten Facetten optional deaktiviert werden kann.
Das bisher nur in der Werkansicht zur Verfügung stehende Widget für die Einordnung von archivalischen Beständen steht jetzt auch in der Vollbildansicht zur Verfügung.
Archiv Widget in der Vollbildansicht
Archivbestände wurden bisher pro Session geladen und im Speicher vorgehalten. Um hier bei vielen Aufrufen einem potentiell großen Speicherverbrauch vorzubeugen wurde dieses Verhalten umgestellt, so dass die Bestände Applikationsweit vorgehalten werden. Dadurch ist der Speicherverbrauch auch bei vielen Zugriffen immer identisch.
Einigen sind die kleinen Indikatoren in der Seitenleiste auf den Screenshots oben vielleicht bereits aufgefallen. Diese stehen ab sofort für die Seite "Zugriffslizenzen" und "Übersetzungen" zur Verfügung und weisen auf potentielle Aufgaben in den Bereichen hin.
Indikatoren in der Sidebar
Die Versionen die in der
pom.xml des Themes eingetragen werden müssen um die in diesem Digest beschriebenen Funktionen zu erhalten lauten:<dependency>
<groupId>io.goobi.viewer</groupId>
<artifactId>viewer-core</artifactId>
<version>22.02</version>
</dependency>
<dependency>
<groupId>io.goobi.viewer</groupId>
<artifactId>viewer-core-config</artifactId>
<version>22.02</version>
</dependency>
<dependency>
<groupId>io.goobi.viewer</groupId>
<artifactId>viewer-connector</artifactId>
<version>22.02</version>
</dependency>
Der Goobi viewer Indexer hat die Versionsnummer 22.02
Das Goobi viewer Crowdsourcing Modul hat die Versionsnummer 22.02
Last modified 10mo ago