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<IDatapoolRecord> 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:

<?xml version="1.0"?>
<datapool>
    <record path="kernel">
        <recordentry key="NODEID" value="06708aeb-ec9b-456d-829e-30c5cfdd6503" description="The node ID." />
        <recordentry key="LICENSE" value="06708aeb-ec9b-456d-829e-30c5cfdd6503" description="The license key." />
        <recordentry key="NAME" value="Node001" description="The name of the node." />
        <recordentry key="VENDOR" value="softdevel GmbH" description="The vendor of this node." />
        <recordentry key="DESCRIPTION" value="Node 001" description="The description for this node." />
    </record>
</datapool>

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.