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!

Als Besitzer eines neuen Mac wollte ich in IPhoto verwenden und habe darin “Ereignisse” ineinander geschoben…

das führte dazu das Bilder, die in beiden “Ereignissen” (am Ende ein Verzeichnis) vorhanden waren, ein “_2″ an den Dateinamen bekamen. Nun hätte per Hand löschen wirklich zu lange gedauert.
Also wollte ich die Konsole bemühen und dachte…

Schön wäre ein

find . -name *_2.jpg | xargs rm

…gewesen.

Leider enthielten die von find gelieferten Pfade aber Leerzeichen. Damit konnte rm dann nichts mehr anfangen.

./Data/2008/04 Rotorua/Picture 157_2.jpg
./Data/2008/04 Rotorua/Picture 158_2.jpg
…

Die Aufgabe war es nun die von find gelieferten Treffer mit Anführungszeichen zu umschliessen, damit rm diese richtig interpretieren und die Datein löschen kann…

nach ein bisschen gefrickel hat es dieser Command getan;

find . -name *_2.jpg | xargs -0 echo | sed ’s,\(.*\),”\1″,’ | xargs rm

leider ging es in der Mac Konsole nicht ohne das zwischengeschaltete echo wenn ich -0 bei xargs gesetzt habe (siehe unten). Wenn ich find -print0 mitgegeben habe sah es so aus als würde sed die Dateien öffnen und den Inhalt ausgeben.

man xargs:

-0      Change xargs to expect NUL (``\0'') characters as separators,
        instead of spaces and newlines.  This is expected to be used
        in concert with the -print0 function in find(1).