Übersicht: Anweisungen der Konfigurationsdatei

Da der Java Service Wrapper seine Konfigurationsdatei parst, wird er in den meisten Fällen jedweden Text, der nach einem '#'-Zeichen kommt, als einen Kommentar behandeln. Es gibt jedoch ein paar Ausnahmen zu dieser Regel.

Der Wrapper folgte geschichtlich bedingt dem Muster der der C-Sprache bezüglich der Definition von speziellen Anweisungen, die verarbeitet werden, wenn die Konfigurationsdatei geladen wird.

Die Kodierung der Konfigurationsdatei

Ab der Wrapper-Version 3.5.0, wurde es möglich, die Kodierung von individuellen Konfigurationsdateien zu spezifizieren. Die am meisten portable Codierung ist UTF-8, aber andere Kodierungen WERDEN auf ein paar Plattformen unterstützt.

Die Kodierung-Anweisung muss in der ersten Zeile einer Konfigurationsdatei spezifiziert werden. Der Wrapper speichert eine Warnung ins Log ab, wenn irgendeine Datei die Anweisung nicht einhält. Es ist möglich verschiedene Kodierungen in include files (kaskadierender Stil) zu spezifizieren

UTF-8 Beispiel: 
#encoding=UTF-8

wrapper.debug=FALSE
...

Einfügen der kaskadierenden Konfigurationsdatei

Es ist möglich, eine Konfiguration in eine oder mehr optionale Konfigurationsdateien aufzuteilen und diese dann von der Hauptdatei aus einzufügen. Sehen Sie bitte die kaskadierende Konfigurationsdatei ("include file")-Seite für mehr Information.

Beispiel: 
#include ../conf/wrapper-settings.conf

Aus Absicht übergeht der Wrapper stillschweigend jede hinzugefügten Datei, welche er nicht in der Lage ist, zu finden oder zu lesen. Diese Funktion kann sehr mächtig sein, da diese ermöglicht, plattformspezifische Konfigurationen zu erstellen, oder optional bestehende Eigenschaftenwerte zu überschreiben.

In einigen Fällen ist jedoch für die ordnungsgemäße Funktion einer Anwendung eine Include-Datei erforderlich. Ab der Wrapper-Version 3.5.5 ist es möglich, eine benötigte Include zu spezifizieren, die einen Fehler verursacht und den Wrapper am Starten hindert, wenn diese fehlt.

Beispiel: 
#include.required ../conf/wrapper-settings.conf

Debug Include Files

Ab der Wrapper Version 3.3.0, ist es möglich eine Fehlerbehebung in der Art, wie die #include-Anweisung funktioniert, durchzuführen, indem man genau erkennt, was eingefügt wurde und was nicht. Sehen Sie bitte die Fehlerbehebungsmeldungen auf der "include file" (kaskadierender Stil)-Seite für mehr Information.

Beispiel: 
#include.debug

Eigenschaften der Fehlerbehebung

Ab der Wrapper Version 3.5.4 ist es möglich, den Wrapper so zu konfigurieren, dass er beim Starten jedes Mal dann eine Nachricht ausgibt, wann immer eine Eigenschaft von einer anderen Deklaration überschrieben wird oder wenn eine Eigenschaft nicht festgelegt werden kann, weil ihr Wert bereits festgelegt ist.

Die Wrapper-Version 3.5.27 verbessert dieses Feature. Es ist nun möglich, die Logebene dieser Nachrichten zu steuern und zu spezifizieren, ob der Wrapper sich nach dem Loggen beenden soll. Sie könnten auch verschiedene Einstellungen für die Abschnitte Ihrer Konfigurationsdateien anwenden und erlaubt Ihnen so in gewisser Hinsicht mehr strikt-genau zu sein. Dies kann durch die Anwendung zweier neuer Anweisungen erreicht werden:

Abhängig von der Art der Eigenschaften gibt der Wrapper verschiedene Nachrichten aus. Dieses Nachrichten werden unten beschrieben.

NOTE

Diese Nachrichten werden standardmäßig nur im Debug-Modus geloggt, da es gängige Praxis ist, Eigenschaftenwerte durch Nutzung optionaler kaskadierender Konfigurationsdatei ("include file"), oder anderer Methoden zu überschreiben.

WARNING

Weil die Eigenschaften wrapper.name und wrapper.displayname im UNIX-Shellskript definiert werden; so dass Sie, wenn Sie dieses Skript nutzen, um den Wrapper zu starten und wenn Sie Problembehebung dieser Eigenschaften unter Nutzung dieser Anweisungen betreiben, werden Sie Warnmeldungen erhalten, da diese Variablen standardmäßig in der Konfigurationsdatei definiert werden.

Sie können diese Nachrichten verhindern, entweder indem Sie die redundanten Eigenschaften in der Konfigurationsdatei entfernen oder durch Auskommentieren der Zeile '#APP_NAME_PASS_TO_WRAPPER=false' in der Skriptdatei.

Die zweite Option bewirkt, dass das Skript diese Parameter nicht mehr dem Wrapper übergibt. Bitte Seien Sie behutsam, nicht die Eigenschaften 'APP_NAME' und 'APP_LONG_NAME' zu deaktivieren, welche zum korrekten Funtkionieren des Skripts benötigt werden.

Nachrichten

Um verstehen zu helfen, warum eine Eigenschaft einen spezifischen Wert hat, kann es nützlich sein, sich vorzustellen, wann sein Wert geändert wurde oder im Gegenteil, wann dies ignoriert wurde, trotz eines Versuchs, diesen zu überschreiben.

Hier sind die Nachrichten, die Sie bekommen können:

Übereinandergreifende Eigenschaften:

Der Wrapper ist eingerichtet, so dass die letztdefinierte Instanz einer definierten Eigenschaft genutzt werden wird. Dies kann eine sehr leistungsfähige Option sein, da Standardwerte eingerichtet werden können und dann auf eine optionale include-Datei verwiesen werden kann, die für ein System spezifische Werte enthalten könnte.

Beispiel der Neudefinition einer Eigenschaft: 
STATUS | wrapper  | Die "foo.bar"-Eigenschaft wurde auf Zeile Nr.8 der Konfigurationsdatei neu definiert: /home/wrapper/conf/wrapper.conf
STATUS | wrapper  |   Alter Wert foo.bar=123
STATUS | wrapper  |   Neuer Wert foo.bar=XYZ

Befehlszeileneigenschaften:

Eigenschaftenwerte, die auf der Wrapper Befehlszeile spezifiziert wurden, sind finalgültig, das bedeutet, dass sie nicht durch werte in der Konfigurationsdatei geändert oder überschrieben werden können. This is very useful because a user can run the Wrapper with a test value without having to actually edit the configuration file.

Beispiel zu einer fina lgültigen Neudefinition der Eigenschaft: 
STATUS | wrapper  | Die "foo.bar" Eigenschaft wurde auf der  Wrapper Befehlszeile definiert und kann nicht überschrieben werden.
STATUS | wrapper  |   Ignoriert die Neudefinition auf #8 der Konfigurationsdatei: /home/wrapper/conf/wrapper.conf
STATUS | wrapper  |   Fester Wert foo.bar=123
STATUS | wrapper  |   Ignorierter Wert foo.bar=XYZ

Interne Umgebungsvariablen:

Der Wrapper legt auch mehrere interne Umgebungsvariablen fest. Dies wird durch die Nutzung von Eigenschaften getan. Wenn die Konfigurationsdatei des Benutzers versucht einige von diesen zu setzen, dann wird der Wrapper dies ignorieren und die Werte, die vom Wrapper erstellt wurden, erhalten.

Abschließendes Beispiel zur Neudefinition von Eigenschaften: 
STATUS | wrapper  | Die "set.WRAPPER_ARCH" Eigenschaft wird durch den Wrapper intern definiert und kann nicht überschrieben werden.
STATUS | wrapper  |   Ignoriert die Neudefinition auf #10 der Konfigurationsdatei: /home/wrapper/conf/wrapper.conf
STATUS | wrapper  |   Fester Wert set.WRAPPER_ARCH=x86
STATUS | wrapper  |   Ignorierter Wert set.WRAPPER_ARCH=special

#properties.on_overwrite.loglevel
Kompatibel :3.5.27
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Diese Anweisung wird genutzt, um die Logebene festzulegen, auf der die Nachrichten geloggt werden sollen.

Gültige Werte beinhalten:

  • NOTICE: um auf der NOTICE-Logebene zu loggen.

  • ADVICE: um auf der ADVICE-Logebene zu loggen.

  • FATAL: um auf der FATAL-Logebene zu loggen.

  • ERROR: um auf der ERROR-Logebene zu loggen.

  • WARN: um auf der WARN-Logebene zu loggen.

  • WARN: um auf der -Logebene zu loggen..

  • STATUS: um auf der STATUS-Logebene zu loggen.

  • INFO: um auf der INFO-Logebene zu loggen.

  • DEBUG: um auf der DEBUG-Logebene zu loggen.

? Please check the English version for a more recent version of this text.

Der Standardwert ist DEBUG.
Beispiel(Loggen der überschriebenen Eigenschaften auf einer Warn-Logebene): 
#properties.on_overwrite.loglevel=WARN

NOTE

Der Nutzen dieser Anweisung #properties.debug wurde mit der Wrapper Version 3.5.27 zugunsten dieser neuen Anweisungen eingestellt, die eine feinere Steuerung der Problembehebungseigenschaften erlauben. Aus Gründen der Rückwärtskompatibilität wird #properties.debug die gleichen Auswirkungen wie #properties.on_overwrite.loglevel=STATUS haben.

#properties.on_overwrite.exit
Kompatibel :3.5.27
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Diese Anweisung wird genutzt, um zu spezifizieren, ob der Wrapper sich beenden sollte, wenn irgendeine Eigenschaft überschrieben würde.

Gültige Werte beinhalten:

  • TRUE: spezifiziert, dass der Wrapper sich beenden sollte, wenn irgendeine Eigenschaft, die dieser Anweisung folgt, überschrieben wird.

  • FALSE: spezifiziert, dass der Wrapper sich nicht beenden sollte, wenn irgendeine Eigenschaft, die dieser Anweisung folgt, überschrieben wird.

Der Standardwert ist FALSE.

Beispiel(Beendigung, wenn irgendeine überschriebene Eigenschaft angetroffen wird): 
#properties.on_overwrite.exit=TRUE

Nutzung

Eine Anweisung ist gültig von der Zeile, in der sie in die Konfigurationsdatei eingefügt wurde, bis zum Dateiende oder bis eine neue Anweisung mit dem gleichen Namen angetroffen würde. Falls gefunden, wird der Wert der neuen Anweisung dann für den folgenden Abschnitt in der Konfigurationsdatei gültig werden.

Wenn eine Eigenschaft innerhalb eines Abschnitts überschrieben würde, wobei #properties.on_overwrite.exit auf TRUE eingestellt wäre, würde eine Nachricht zumindest auf einer FATAL-Ebene geloggt werden ( es würde auf ADVICE- oder NOTICE-Ebene verbleiben, wenn es zuvor so mit der '#properties.on_overwrite.loglevel' Eigenschaft festgelegt worden wäre).

Beispiel: 
wrapper.name=@app.name@
wrapper.lang.folder=../lang
...

#properties.on_overwrite.loglevel=STATUS
wrapper.lang.folder=../../lang
...

#properties.on_overwrite.loglevel=INFO
wrapper.name=newAppName
...

#properties.on_overwrite.exit=TRUE
wrapper.app.parameter.3=start
...

wrapper.app.parameter.3=start_app
...

#properties.on_overwrite.exit=FALSE
...

In der oben genannten Konfiguration wird wrapper.lang.folder auf einer 'STATUS'-Ebene geloggt werden, wrapper.name wird auf einer 'INFO'-Ebene und wrapper.app.parameter.3 auf einer 'FATAL'-Ebene geloggt werden, was bewirken würde, dass der Wrapper sich beendet. Jede Eigenschaft, die der Eigenschaft '#properties.on_overwrite.exit=FALSE' folgt, veranlasst den Wrapper nicht, sich zu beenden und wird auf einer 'INFO'-Ebene, so wie zuvor gesetzt, geloggt werden.

NOTE

Ab der Version 3.5.27, wird der Wrapper auch Nachrichten loggen, wenn die Befehlszeile vervielfältigte Eigenschaften enthält oder versucht, eine interne Umgebungsvariable zu setzen.

Sie können weiterhin die Eigenschaften #properties.on_overwrite.loglevel und #properties.on_overwrite.exit nutzen, um die Logebene, auf der diese Nachrichten erscheinen sollen, zu überwachen und um zu spezifizieren, ob der Wrapper sich selbst nach dem Loggen beenden soll. Wenn mehrfache Anweisungen in der Konfigurationsdatei eingestellt wären, kommt die letzte Anweisung jeden Typs zur Anwendung.

Verweis: Protokollierungsstufe
  • wrapper.console.loglevel (1.0.0)

    Filtert Nachrichten, die an die Konsole gesendet werden, nach ihren Protokollierungsstufen.

  • wrapper.logdialog.loglevel (3.3.1)

    Filtert Nachrichten des Log-Dialogs entsprechend ihrer Protokollierungsstufen.

  • wrapper.logfile.loglevel (2.2.5)

    Filtert an die Logdatei gesendete Nachrichten entsprechend ihrer Protokollierungsstufen.

  • wrapper.syslog.loglevel (2.2.5)

    Filtert Nachrichten, die an das Syslog (oder Ereignislog unter Windows) gesendet werden, entsprechend ihren Protokollierungsstufen.