In der neuen Kategorie “Bücher” werde ich in Zukunft meine Meinung zu Büchern schreiben, die ich in letzter Zeit gelesen oder überflogen habe.
Generell kaufe ich mir seit einiger Zeit keine Fachbücher mehr und habe mir stattdessen einen Account bei safaribooks.com angeschafft. Ohne Zweifel eine der besten Investitionen im vergangenen Jahr. Vor allem die Suchfunktion in einer riesigen Menge von Fachbüchern und die Möglichkeit Code und Beispiele direkt zu kopieren machen sich dabei bezahlt, ganz abgesehen von den großen Mengen eingesparten Papiers und Platz in meinem Bücherregal.

Im JBoss 4.2.2 muss man das Startscript anpassen um die Logausgaben einer Anwendung erfolgreich auf die Konsole zu bekommen… hm.

Das Logging von JBoss wird mit der Datei conf/jboss-log4j.xml gesteuert.
In dieser Datei ist dann konfiguriert wie JBoss Logs schreibt.

Wenn man in der log4j.xml der deployten Anwendung den root-Logger auf die Konsole schreiben lässt, sagt einem JBoss “invalid console appender config detected, console stream is looping” … ???

Damit JBoss das Anwendungslogging wie erwartet auf der Konsole ausgibt, muss man beim Start folgende Zeile mitgeben:

set JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.logging.Log4jService.catchSystemOut=false

Damit leitet der JBoss das Logging aller Anwendungen auf die Konsole um und verschluckt diese nicht mehr.

….ist klar !?!

Ant erlaubt es properties zu definieren auf die im Build Prozess zugegriffen werden kann.
Um den Buildprozess konfigurierbar zu halten ist es sinnvoll, Werte die sich ändern können, als Properties zu definieren. In diese Kategorie fallen zum Beispiel Pfadangeben und Dateinamen.

Manche dieser Properties hängen von der Umgebung ab, aus der der Build aufgerufen wird.
So ist es wahrscheinlich, dass sich die Pfadangabe für ein Deploymentverzeichnis auf einer Continuous Integration Umgebung (z.B. unter Linux) von der in einer Entwicklungsumgebung (z.B. Windows) unterscheidet.

Deshalb muss man Ant dazu bringen die für die aktuelle Umgebung passenden Properties zu verwenden.

1. Properties anhand des angemeldeten Benutzers

Wenn eine Datei mit dem Anmeldenamen als Prefix (z.B.: fkrueger.build.properties) existiert, wird diese verwendet.

2. Properties anhand einer Umgebungsvariable

Wenn keine Properties Datei passend zum Anmeldenamen existiert, aber env als Umgebungsvariable (z.B. durch den Aufruf >ant -Denv=my) gesetzt wurde, wird diese verwendet.

3. Build abbrechen wenn Properties Datei nicht existiert

An dieser Stelle macht es Sinn den Build abzubrechen wenn keine Properties Datei gefunden werden konnte.

4. Eventuell Umgebungsabhängige Properties voraussetzen

Unter Umständen macht es Sinn keine Standard Datei build.properties zu haben sondern nur ein Template build.properties.tmpl anzubieten, dass für jede Umgebung angepasst werden muss.
Dann kann der Build abgebrochen werden, wenn kein prefix gesetzt wurde.

5. Properties lesen

Jetzt können die Properties aus der passenden Datei gelesen werden.

6. Dem Aufrufer mitteilen aus welcher Datei die properties gelesen werden

7. Die Properties ausgeben

	
		--> env: ${env}
		--> deploy.dir = ${deploy.dir}
	

Zu beachten: Properties können nicht überschrieben werden, wenn sie einmal gesetzt wurden!