Problem

Einige Services spielen beim Start einmalig Daten ein: der AccessConfigurationSetupService (security.xml), der InitialDataSetupService (*.objects.xml), der InitialProcessSetupService (BPMN-Prozesse) und das ImportDocumentationModule (Dokumentation). Sie bieten anderen Services nichts an, brauchen selbst aber möglichst viel vom laufenden System.

Als Services werden sie in der Reihenfolge ihrer Abhängigkeiten gestartet. Welche Services sie tatsächlich brauchen, hängt aber von den eingespielten Daten und der Anwendung ab und lässt sich nicht vollständig als Abhängigkeit angeben. Beispiel: Der Import der security.xml ermittelt die Befehlsgruppen der Layouts (#29917). Dabei werden die Komponenten-Konfigurationen der Anwendung ausgewertet, die je nach Komponente weitere Services benötigen (z.B. CommandHandlerFactory, ExportHandlerRegistry). Ob diese bereits laufen, hängt von der Startreihenfolge der jeweiligen Anwendung ab. Services aus höheren Modulen kann com.top_logic zudem nicht als Abhängigkeit nennen.

Für die Startaktionen der automatischen Datenmigration (<startup-actions> in *.migration.xml) gibt es einen solchen Zeitpunkt bereits: AbstractStartStopListener ruft nach ModuleUtil.startConfiguredModules() MigrationService.applicationStarted() auf. Dieser Mechanismus ist aber auf die Migration beschränkt.

Lösung

Start-Haken

Ein neuer Service StartupHooks führt die konfigurierten Start-Haken aus, nachdem alle Services gestartet sind. Jeder Haken ist eine StartupAction, wie die Startaktionen der Migration.

{{{#!xml <config service-class="com.top_logic.util.StartupHooks"> <instance class="com.top_logic.util.StartupHooks"> <hooks> <hook id="access-configuration" on-error="log-error" > <action class="com.top_logic.tool.boundsec.config.AccessConfigurationSetup"/> </hook> </hooks> </instance> </config> }}}

• Die Haken laufen in der Reihenfolge der Liste. Module erweitern die Liste über ihre Konfiguration, Anwendungen können Haken über die id ansprechen (z.B. config:position, config:operation="remove").
• on-error legt fest, was bei einem Fehler des Hakens passiert: fail (Voreinstellung, der Start wird abgebrochen), log-error oder log-warn (der Fehler wird protokolliert, die übrigen Haken laufen weiter).

Ausführung

• Zuerst laufen wie bisher die Startaktionen der Migrationen in der Start-Transaktion (MigrationService.applicationStarted()).
• Nach dem Commit der Start-Transaktion laufen die konfigurierten Haken, jeder in einer eigenen Transaktion. Eine verschachtelte Transaktion, die zurückgerollt wird, markiert die äußere Transaktion als gescheitert. Ein Haken mit log-error oder log-warn könnte daher innerhalb der Start-Transaktion nicht scheitern, ohne den Start abzubrechen.
• Ob ein Haken bei jedem Start oder nur bei geänderten Daten etwas tut, entscheidet die Aktion selbst (z.B. über einen Hash in DBProperties).
• Anwendungstests (ApplicationTestSetup) starten die Anwendung über AbstractStartStopListener und führen die Haken damit ebenfalls aus.

Umzug

Die vier Setup-Services der Engine sind jetzt Start-Haken (jeweils mit on-error="log-error", wie bisher):

initial-data läuft vor access-configuration, damit die Rechte auf die eingespielten Daten treffen. Die statischen Hilfsmethoden und Konstanten (z.B. InitialProcessSetup.importWorkflow(), InitialDataSetup.FILE_SUFFIX, AccessConfigurationSetup.hash()) sind an die neuen Klassen gewandert. Die in DBProperties gespeicherten Markierungen bleiben unverändert, bereits eingespielte Daten werden nicht erneut importiert.

Zwei Services der KI-Module warteten auf diese Setup-Services und sind ebenfalls Start-Haken (jeweils mit on-error="fail", der Start wird wie bisher abgebrochen):

• AgentNameCheck prüft die Agenten der Zugriffsrichtlinie nach dem Daten-Import, der Agenten anlegen kann. Der AiToolAccessService lässt die Agenten-Namen beim Start deshalb immer aus.
• SecDemoSetup vergibt zusätzliche Komponentenrechte. Es läuft nach dem Import der security.xml, da dieser alle Rechte zurücksetzt. Die Konfiguration der Sicherheits-Demo ist jetzt die Konfiguration der Aktion des Hakens secdemo.

#29917 setzt auf diesem Ticket auf.

Migration

Die folgenden Module gibt es nicht mehr: InitialDataSetupService$Module, AccessConfigurationSetupService$Module, InitialProcessSetupService$Module, ImportDocumentationModule$Module, AgentNameCheck$Module und SecDemoSetupService$Module. Nennt eine Anwendung eines davon in ihrer Modul-Konfiguration (<module key="...$Module" .../> in der Konfiguration des ModuleSystem), muss der Eintrag entfernt werden.

Sollte ein solcher Service abgeschaltet werden (value="false"), wird stattdessen der zugehörige Haken entfernt:

{{{#!xml <config service-class="com.top_logic.util.StartupHooks"> <instance> <hooks> <hook id="initial-workflows" config:operation="remove" /> </hooks> </instance> </config> }}}

Eine Anwendung, die die Konfiguration der Sicherheits-Demo überschreibt (<config service-class="com.top_logic.ai.demo.secdemo.SecDemoSetupService">), konfiguriert stattdessen die Aktion des Hakens secdemo:

{{{#!xml <config service-class="com.top_logic.util.StartupHooks"> <instance> <hooks> <hook id="secdemo"> <action class="com.top_logic.ai.demo.secdemo.SecDemoSetup" initial-password="..." /> </hook> </hooks> </instance> </config> }}}

Ein Service, der bisher über @ServiceDependencies auf einen der Setup-Services wartete, um die eingespielten Daten zu sehen, wird selbst zum Start-Haken, der nach dem entsprechenden Haken konfiguriert ist (config:position="after" und config:reference="<id>").

Wer die Klassen direkt verwendet (z.B. InitialProcessSetupService.importWorkflow() oder InitialDataSetupService.FILE_SUFFIX), stellt auf die neuen Klassennamen um.