Installation ############ Das devel.one Framework kann auf zweierlei Art verwendet werden: - StandAlone devel.one läuft allein als Programm und lädt Apps als PlugIn. - Eingebettet Ein existierendes Programm lädt und initialisiert die devel.one-Library. - Als JAR-Datei im Classpath kann einfach die Klasse CKernel instanziiert werden. Daraufhin sind alle Funktionen auch in anderen Programmen verfügbar. - Die main-Methode des Kernels kann aufgerufen werden. Devel.one startet dann als eigenständiges Programm, lädt seine Konfigurationsdateien sowie die PlugIns. Die eigene Applikation kann dann als PlugIn beim StartUp starten. Alternativ kann man auch eine APP erstellen, welche beim StartUp oder auch zu einem späteren Zeitpunkt gestartet werden kann. Programm-Argumente ****************** Jede devel.one Instanz benötigt zumindest ein eigenes Verzeichnis, in dem es die Konfigurationsdateien erwartet. Außerdem werden dort Dateien vom Programm angelegt, z.B. eine H2-Datenbank mit den persistierten Konfigurations- und Laufzeit-Variablen. Das Verzeichnis und diverse andere Einstellungen werden als Programm-Argumente übergeben. Das Format der Programm-Argumente:: pfad/schlüssel=wert Beispiel:: kernel/ConfigDir=config/ In diesem Fall ist ``kernel`` der *PFAD* (könnte auch wie ein Windows Registry Pfad aussehen, z.B. ``a/b/c/d``), ``ConfigDir`` ist der *SCHLÜSSEL* und ``wert`` ist der Konfigurations-*WERT*. Standalone ********** Die main-Methode des Kernels wird aufgerufen. Devel.one startet dann als eigenständiges Programm, lädt seine Konfigurationsdateien sowie die PlugIns. Die eigene Applikation wird als als PlugIn beim StartUp geladen. Im StandAlone-Modus werden dringend benötigte Konfigurationswerte als Programm-Argumente übergeben. Alle anderen Argumente können in einer Konfigurationsdatei übergeben werden. Kommandozeile ============= Ein typischer Aufruf einer devel.one-StandAlone-Instanz sieht etwa so aus:: // -cp lib/* Der ClassPath, in dem sich auch die D1Kernel.jar befindet. // -Dlogback.configurationFile=config/logback.xml Ein VM Argument für die Konfiguration des LOGBACK Logging Systems. // de.softdevel.d1.kernel.impl.CKernel Hier befindet sich die zu startende main-Methode. // kernel/ConfigDir=001/config/ Ein Programm-Argument: Verzeichnis der Konfigurationsdateien // kernel/PluginDir=common/plugins/ Ein Programm-Argument: Verzeichnis der zu ladenden PlugIns // kernel/RecordDbFile=common/recorddb.xml Ein Programm-Argument: Datei der Message Datenbank java -cp lib/* -Dlogback.configurationFile=config/logback.xml de.softdevel.d1.kernel.impl.CKernel kernel/ConfigDir=config/ kernel/PluginDir=common/plugins/ kernel/RecordDbFile=common/recorddb.xml Embedded ******** Der devel.one Kernel kann einfach gestartet werden, indem eine Instanz der Klasse mit ``new`` angelegt wird. Die Konfigurations-Argumente werden als Parameter mitgegeben:: final Collection args = new ArrayList<>(); args.add(new CDatapoolRecord("kernel", "ConfigDir", "c:\test", "Path of Configuration Files", true)); IKernel kernel = new CKernel(args); Es kann nur ein einziger Kernel im Programm initialisiert werden. Das könnte sich später einmal ändern. Die wichtigsten Programm-Argumente ********************************** * **Das Konfigurations-Verzeichnis:** | Es gibt für jede zu startende devel.one-Instanz ein Konfigurationsverzeichnis. | Lege am besten ein Verzeichnis im HOME-Verzeichnis an, wie z.B. c:/user/michael/d1_01. | Jede Instanz benötigt ein eigenes Verzeichnis, da dort Daten in eine H2-Datenbank-Datei persistiert werden. | Zudem wird in diesem Verzeichnis die Konfigurationsdatei *datapool.xml* erwartet. Das Verzeichnis übergibt man als Programm-Argument. Beispiel:: kernel/ConfigDir=c:\user\michael\d1config01 | ``kernel/ConfigDir`` ist hier der Konfigurations-Schlüssel. | ``c:\user\michael\d1config01`` ist hier der anzugebende Wert. | Die im Verzeichnis optional enthaltenen Konfogurationsdateien werden weiter unten beschrieben. * **Verzeichnis für interne LOG-Dateien:** Beispiel:: kernel/LogDir=c:\user\michael\d1config01\log | Dieses Verzeichnis wird für interne LOGs verwendet, wie für den GateKeeper. | Das LOGBACK Logging System benutzt eine eigene Konfigurationsdatei, dessen Pfad via VM-Argument angegeben werden kann. * **Das PlugIn-Verzeichnis:** Beispiel:: kernel/PluginDir=c:\user\michael\d1\plugins Das PlugIn-Verzeichnis kann von allen Instanzen geteilt werden. Es gibt noch eine Menge anderer Konfigurationsschlüssel, welche weiter unten gelistet werden. Liste der gebräuchlichsten Programm-Argumente ********************************************* +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | Pfad + Schlüssel | Variablen Typ | Bedeutung | Beispiel | +=======================================+================+==================================+======================================+ | kernel/NODEID | UUID | NODE-ID | 06708aeb-ec9b-456d-829e-30c5cfdd6503 | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/LICENSE | UUID | Lizenz-ID | 06708aeb-ec9b-456d-829e-30c5cfdd6503 | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/NAME | String | Name des NODES | Node001 | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/VENDOR | String | Vendor des NODES | softdevel GmbH | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/DESCRIPTION | String | Beschreibung des NODES | NODE für UI | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/DebugEnvelope | Boolean | Message Debug Info im Stream | true | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/LogDir | String | Log Dir für GateKeeper | ./log | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/ConfigDir | String | Pfad der Konfigurationsdateien | . | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/PluginDir | String | Pfad der PlugIns | ../plugins | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/DumpDatapool | Boolean | True: Dump der Konfiguration | False | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/MaximumSavedEarlyLogs | Integer | Anzahl gespeicherter LOG-Texte | 10000 | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | kernel/EnablePrintingEnvironment | Boolean | True: Print Environment | True | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ | namespaces/XXX/OwnDatapool | Boolean | True: Datapool für Namespace XXX | True | +---------------------------------------+----------------+----------------------------------+--------------------------------------+ Die Konfigurations-Datei ************************ | Der Name der Konfigurations-Datei ist in der D1 Version 1.0 immer ``datapool.xml``. | Sie wird im instanz-spezifischen Konfigurationsverzeichnis erwartet. Beispiel:: Das Format ist dasselbe wie bei den Programm-Argumenten: ``path/key=value``. Die Werte werden nach dem Einlesen im Datenpool gespeichert. Das ist ein Service, welcher die Werte in einer SQL Datenbank persistiert. Die Werte können von Apps durch Methodenaufrufe oder auch durch Nachrichten gelesen und geschrieben werden. Außerdem unterstützt der Datenpool das Observer-Pattern. Apps können sich beim Datenpool als Observer eintragen lassen und bekommen z.B. eine Nachricht, wenn ein Wert sich verändern sollte. Das ``readonly``-Attribut sorgt dafür, das der Wert nach der Eintragung in der Datenbank nicht mehr geändert werden kann, solange das Programm läuft. Befindet sich ein Wert schon in der Datenbank, so wird er nicht durch die Konfiguration überschrieben. Er ist also geschützt abgelegt. Sollte er dennoch überschrieben werden, so ist das Attribut ``force`` zu verwenden. Das Element ``description`` ist optional. Die Reihenfolge beim Importieren von Konfigurations-Werten ********************************************************** - | Der Kernel sucht das Programm-Argument ``kernel/ConfigDir``, um die Konfigurationsdatei zu finden. | Der Wert bezeichnet das Konfigurations-Verzeichnis der Instanz, in dem auch die Datenbank-Datei gespeichert wird. - Alle Werte der Konfigurations-Datei werden nun importiert. - | Nun werden die Programm-Argumente eingetragen. | Existiert schon ein Programm-Argument, wird es nur eingetragen, wenn das Attribut ``force`` gesetzt wird. | Da der Default-Wert true ist, ist es so, dass mit force=false ein vorhandener Wert in der Datenbank NICHT überschrieben wird.