von Roman Seibold

In meinem letzten Beitrag zum Thema WebSphere habe ich von der neuen Möglichkeit des WebSphere Application Servers V7 berichtet, mit sogenannten Property-Dateien Konfigurationsdaten auszulesen und zu verändern. [Beitrag]

Heute möchte ich ein paar zusätzliche Worte zu diesem neuen Feature verlieren.

Zunächst einmal nochmals zur Erinnerung. Über wsadmin, und nur über wsadmin, der skriptgesteuerten Konfigurationsvariante des Applicationservers, konnte man sich mit

AdminTask.extractConfigProperties(
  '-propertiesFileName demo.props')

eine Datei namens "demo.props" im Property-Format ("property=value" Paare) besorgen.
Ein besonderes Property-Format, weil Reihenfolgen auch eine Rolle spielten.

Wenn man sich die erzeugte Datei genauer ansieht, trifft man in manchen Zeilen auf merkwürdige Einträge, wie z.B. diesen hier:

WC_defaulthost=9080:!{hostName1} # integer

WC ist hier nicht das, woran man eventuell in einem ersten schwachen Moment denkt, sondern die bei IBM oft genutzte Abkürzung für "Web-Container". Der Web-Container-Default-Host hat also Port-Nummer 9080, eine Zahl, die gestandene WebSphere-Kenner nicht überraschen sollte.
Für ein Property liegt aber dennoch ein merkwürdiges Format vor, da nach dem Wert 9080 noch eine weitere Information folgt :!{hostName1}. Der Zusatz # integer ist ein Kommentar bezüglich des Wertebereiches für das Property.

hostName1 hingegen ist eine Variable, mit der die Property-Files erst so richtig interessant werden. Definiert werden die Variablen in frisch erzeugten Property-Files immer ganz am Ende. Dort findet man folgenden Abschnitt:

#
EnvironmentVariablesSection
#
#
#Environment Variables
hostName2=localhost
hostName1=*
cellName=was70host00Cell01
nodeName=was70host01Node01
hostName=was70host01
serverName=server1

Man könnte jetzt die Variablen-Sektion verändern, wenn man die Werte auf einen anderen Server aufspielen will. Interessanter ist aber, diesen Teil ganz aus der Property-Datei zu entfernen und in eine eigene Datei zu legen, die dann nur aus der Environment- Variables-Section besteht. Nennen wir das File "var.props". Hierin kann man dann auch eigene Variablen definieren, z.B.

WC_defaulthost_value=9080

Und in der anderen Datei - "demo.props" - die weiter oben zitierte Zeile anpassen

WC_defaulthost=!{WC_defaulthost_value}:!{hostName1}

Jetzt haben wir eine generischere Konfigurationsdatei und eine Datei, in der die Variablen gemappt werden. Beide kann man von wsadmin zusammenführen lassen und validieren. Nach erfolgreicher Validierung lässt sich alles wieder zurück in das Konfigurationsarchiv übertragen:

AdminTask.validateConfigProperties(
  '-propertiesFileName demo.props 
   -variablesMapFileName var.props')
AdminTask.applyConfigProperties(
  '-propertiesFileName demo.props 
   -variablesMapFileName var.props')
AdminConfig.save()

Man kann also mit -variablesMapFileName ein weiteres File angeben, in dem nur die Variablen und ihre derzeitige Belegung enthalten ist. Mit einer weiteren Option -variablesMap lassen sich sogar direkt im wsadmin-Command die Properties belegen.
Das ist natürlich nur sinnvoll, wenn man wenige Variablen hat, oder wenn wsadmin als Skriptfile (vielleicht sogar mit Parametern) ausgeführt wird und man die Map programmatisch füllen kann. Leider funktionieren die beiden Optionen nicht zusammen. Die Idee, die größere Anzahl an Variablen im Map-File bereits zu setzen und dann einige über die Command-Line nachträglich zu liefern, ist den WebSphere-Architekten offenbar nicht gekommen. Hier gilt ein striktes "Entweder-Oder", ansonsten erntet man NullPointerExceptions.

Trotzdem, schon bei diesem simplen Beispiel deutet sich an, wie flexibel und mächtig dieses neue Feature dennoch ist. Man kann komplette Konfigurationen vorgeben, die einige variable Teile enthalten und diese - und nur diese! - werden dann jeweils ersetzt. Viel einfacher als ein Skript,
viel wiederverwendbarer als eine Administration über die Web-Oberfläche.

Probieren Sie es einfach mal aus und schreiben Sie uns Ihre Erfahrungen - wir freuen uns auf Ihre Kommentare.

Bis dahin verbleibe ich mit konfigurativen Grüßen, Ihr

Roman Seibold