Eine allgemeine Konfiguration kann durch eine speziellere Konfiguration überschrieben werden. Diese Reihenfolge wird durch mehrere Faktoren bestimmt:

• Kategorie der Konfigurationsdatei:
  • Normale Konfiguration
  • Test-Konfiguration
    • Spezielle Test-Konfiguration
    • Normale Test-Konfiguration
  • Persönliche Konfiguation
• Abhängigkeiten der Eclipse Projekte voneinander
• metaConf.txt Dateien

Dabei bestimmt die Kategorie der Konfigurationsdatei die grobe Position in der oben angegebenen Reihenfolge. Das heißt zum Beispiel, alle "normalen Konfigurationen" kommen vor allen "Test-Konfigurationen". Die metaConf Dateien legen die Reihenfolge zwischen Dateien derselben Kategorie im selben Projekt fest. Außerdem regeln die metaConf Dateien, welche Konfigurationsdateien überhaupt verwendet werden.

Weitere Faktoren

• Bei JUnit-Tests wird die persönliche Konfiguration nicht verwendet. Damit soll sichergestellt werden, dass bei allen Entwicklern das gleiche getestet wird. Das soll vermeiden, dass ein Test bei einem Entwickler funktioniert aber bei anderen fehlschlägt.
  • Die persönliche Konfiguration kann trotzdem verwendet werden. Dazu muss in der Launch-Konfiguration folgendes VM Argument hinzugefügt werden: -Dproject.developer=${project.developer}
• Bei Anwendungstests werden die Test-Konfigurationen nicht verwendet. Damit soll sichergestellt werden, dass die an den Kunden gelieferte Anwendung funktioniert, nicht nur eine speziell für die Tests konfigurierte Anwendung.
  • Anwendungstests sind geskriptete Tests (also zum Beispiel Excel Tests) und alle anderen Tests, die ApplicationTestSetup.setupApplication(...) nutzen.
  • Falls bei einem Anwendungstest die Test-Konfigurationen verwendet werden sollen, muss ApplicationTestSetup.setupTestApplication(...) verwendet werden.

Arten von Konfigurationsdateien

Normale Konfigurationen

• Normale Konfigurationsdateien sind diejenigen, die in den metaConf.txt und metaConf.txt.local Dateien stehen.
• Sie sind die eigentlichen Konfigurationsdateien und enthalten den größten Teil der Konfiguration. Alle anderen Konfigurationsdateien passen diese nur für spezielle Zwecke an, zum Beispiel für Tests.
• Beispiele:
  • com.top_logic.basic/webapp/WEB-INF/conf/tl_basic.xml
  • com.top_logic/webapp/WEB-INF/conf/top-logic.xml
  • com.top_logic.element/webapp/WEB-INF/conf/ElementConf.xml

Test-Konfigurationen

Test-Konfigurationen werden nur für Tests verwendet. Sie dienen dazu Einstellungen vorzunehmen, die nur für Tests notwendig sind. Damit soll verhindert werden, Konfigurationen in der produktiven Anwendung vorzunehmen, die nur für Tests notwendig sind.

Spezielle Test-Konfiguration

• Ein Teil der Test-Konfigurationen wird hart-kodiert eingebunden. Darum kümmert sich ConfigLoaderTestUtil.setupConnectionPoolRegistry().
• Beispiele:
  • com.top_logic.basic/test/webapp/WEB-INF/conf/testingConnectionPool.xml
  • com.top_logic.basic/test/webapp/WEB-INF/conf/test-with-mysql.xml
  • com.top_logic.basic/test/webapp/WEB-INF/conf/test-with-h2.xml

Normale Test-Konfiguration

• Normale Test-Konfigurationen sind Dateien, deren Name mit .test.xml endet.
• Es darf nur eine pro Projekt geben. (Sonst wird eine Exception geworfen.)
• Es wird nur die Test-Konfiguration aus dem gestarteten Projekt verwendet. Ein Test in com.top_logic.element lädt also nur die element.test.xml, nicht aber die top-logic.test.xml.
• Test-Konfigurationen liegen normalerweise in einem eigenen webapp-Verzeichnisbaum, um sie von den normalen Konfigurationsdateien getrennt zu halten.
  • Normale Konfigurationsdatei: com.top_logic/webapp/WEB-INF/conf/
  • Test-Konfigurationsdatei: com.top_logic/test/webapp/WEB-INF/conf/
• Beispiele:
  • com.top_logic/test/webapp/WEB-INF/conf/top-logic.test.xml
  • com.top_logic.element/test/webapp/WEB-INF/conf/element.test.xml

Persönliche Konfigurationen

• Wichtig: Die persönliche Konfiguration wird nicht berücksichtigt, wenn die Anwendung deployed ist.
• Wichtig: Die persönliche Konfiguration wird nicht berücksichtigt, wenn bereits eine Konfiguration anhand des Anwendungsnamens gefunden wurde. (Siehe oben)
• Die persönliche Konfiguration liegt immer unter: /bin/launch/conf/config-xxx.xml
  • "xxx" entspricht dabei dem Entwickler-Kürzel, also zum Beispiel "jst".
• Die persönliche Konfigurationen sind Entwickler spezifische Konfigurationsdateien. Sie sind dafür da, die Anwendung entsprechend der eigenen Bedürfnissen und Vorlieben anzupassen. Diese Konfigurationsdateien werden nur für ihren jeweiligen Entwickler verwendet.
• Die persönliche Konfiguration wird durch das VM Argument -Dproject.developer=${project.developer} definiert.
  • project.developer ist ein in Eclipse eingetragener Parameter der durch das Entwickler-Kürzel ersetzt wird.
  • Meistens ist das Kürzel 3-stellig. Aber das ist nur Konvention. Technisch gesehen ist die Länge egal.
• Die persönliche Konfiguration (config-abc.xml) kann entsprechend ihres Inhalts auf die Projekte verteilt werden und wird dann wie die normalen Konfigurationen aus allen Projekten zusammengesetzt.

Ordner deploy

deploy/local

In diesen Ordnern gibt es eine weitere webapp Struktur. Diese enthält Konfigurationen, die nur für dieses Eclipse-Projekt verwendet werden sollen. Wenn andere Projekte von diesem Projekt anleiten, verwenden sie diese Dateien nicht.

In der B.O.S.-Infrastruktur wird dieser Ordner außerdem für das Deployment verwendet. Wenn kein anderer deploy Ordner angegeben wird, wird der oberste deploy/local Ordner verwendet. In com.top_logic ist dort die H2-Datenbank eingetragen. Dadurch können Anwendungen ohne zusätzliche Einstellungen deployt werden.

Dieser Ordner kommt unmittelbar nach der normalen Konfiguration des Eclipse-Projektes. Dadurch können hier Einstellungen der normalen Anwendungskonfiguration überschrieben werden.

deploy/private

In diesen Ordnern gibt es eine weitere webapp Struktur. Diese enthält Konfigurationen, die nur innerhalb der B.O.S. verwendet werden. Zum Beispiel die Einstellungen für unseren LDAP-Server. Dateien in diesen Ordnern werden nicht in .war Dateien übernommen und nicht im TL-Studio ausgeliefert.

In der B.O.S.-Infrastruktur wird dieser Ordner für Deployments verwendet, wenn kein deploy-Ordner angegeben wurde. Siehe auch: Docker Deployment

Die deploy/private Ordner kommen nach dem normalen webabb Ordner ihres Projektes. Sie kommen auch nach einem eventuellen deploy/local Ordner. Dadurch können hier allgemeine Einstellungen innerhalb der B.O.S.-Infrastruktur vorgenommen werden, die die normalen Projekt-Einstellungen überschreiben.

Der deploy/private Ordner eines Projektes kommt vor allen webapp und deploy Ordnern von abhängigen Projekten. Beispiel:

• com.top_logic.demo\deploy\private\webapp
• com.top_logic.demo\deploy\local\webapp
• com.top_logic.demo\webapp
• com.top_logic.element\deploy\private\webapp
• com.top_logic.element\webapp

metaConf.txt

• Jedes Projekt hat eine metaConf.txt Datei. Diese befindet sich unter webapp/WEB-INF/conf.metaConf.txt. Diese definiert welche normalen Konfigurationsdateien eingebunden werden, und in welcher Reihenfolge. Das gilt für dieses Eclipse-Projekt selber sowie alle abhängigen Eclipse Projekte.
• metaConf.txt.local Dateien gibt es nicht mehr. Deren Funktion wurde von den deploy/local Ordnern übernommen.

Überprüfen der Reihenfolge beim Debuggen

Die laufende Anwendung mit einem Breakpoint anhalten und in der Eclipse-View namens "Debug Shell" folgenden Code ausführen:

com.top_logic.basic.XMLProperties.getInstance().toString()

Das liefert die Reihenfolge der Konfigurationsdateien. Beispiel:

com.top_logic.basic.XMLProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.basic\webapp\WEB-INF\conf\tl_basic.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.basic\webapp\WEB-INF\conf\devel-host.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.convert\webapp\WEB-INF\conf\tl_convert.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.dob\webapp\WEB-INF\conf\tl_dob.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.dsa\webapp\WEB-INF\conf\tl_dsa.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.basic.db\webapp\WEB-INF\conf\basicDbConf.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.basic.db.schema\webapp\WEB-INF\conf\basicDbSchemaConf.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic.dob.persist\webapp\WEB-INF\conf\dobPersistConf.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic\webapp\WEB-INF\conf\top-logic.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic\webapp\WEB-INF\conf\devel-appdata.xml']
com.top_logic.basic.MultiProperties [BinaryContent: 'file:D:\development\workspaces\prime_0\com.top_logic\webapp\WEB-INF\conf\devel-smtpTestConf.xml']
...

Tests mit anderer Datenbank ausführen

• Beispiel: H2 statt MySQL
• Launch-Konfiguration anpassen und folgende VM Argumente hinzufügen:
  • -Dtl.test.defaultDB=h2
  • -Dtl.test.onlyDefaultDB=true