PINC-Blog

Griffon: Mit einem “Flügelschlag” außer Gefecht gesetzt

Rob — Thu, 04 Mar 2010 19:20:28 +0000

Es gibt ein Sprichwort: “Kleinchen heb die Beinchen jetzt kommen Steinchen”. So geschehen bei mir, als ich das erste Mal Griffon unter Windows ausprobieren wollte.

Es ließ sich Partout nicht starten und belegte mich mit der Meldung, dass meine “JAVA_HOME”-Variable auf ein invalides Verzeichnis verweisen würde. Leider konnte ich auf dem System nicht die JAVA_HOME direkt ändern, sondern musste diese in den Umgebungsvariablen des Benutzers “überschreiben”. Ist dann schon etwas unschön, aber gut – es ging erstmal ans Werk.

Nun ist man ja als alteingesessener Java-Entwickler daran gewöhnt, dass Pfade mit Leerzeichen nie gut ankommen. Also 1. Versuch: Leerzeichen entfernen – Kein Erfolg. Einmal ist keinmal, also nächster Versuch: Suchmaschine bemühen – wenig Erfolg.

Die Suche gab zwar nicht die vollständige Antwort, aber zumindest einen Anhaltspunkt. Der abschließende Backslash im Pfad könnte ein Problem sein. Zwar führte dieser Ansatz erstmal zu einem gewissen Erfolg, aber einfach mal eine Systemvariable überschreiben – auch wenn es nicht so große Unterschiede gab – fand ich nicht so “prickelnd”. Darum kam am Ende der Texteditor zum Einsatz, denn mir war aufgefallen, dass Groovy selbst z.B. keine Probleme mit dem Pfad hatte.

Und da war sie – die Lösung, die ich gesucht hatte:

@rem Remove trailing slash from JAVA_HOME if found
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%

Mit dieser Zeile wird einfach das abschließende Backslash entfernt. Diese Zeile in die startGriffon.bat unter :have_JAVA_HOME geschrieben und plötzlich funktioniert es auch mit dem Greif.

:have_JAVA_HOME
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%
@rem Validate JAVA_HOME
%COMMAND_COM% /C DIR "%JAVA_HOME%" 2>&1 | %FIND_EXE% /I /C "%JAVA_HOME%" >nul

Leider wurde das Problem auch in der aktuellen Version 0.3 nicht gefixt.

Trac-Themes

Rob — Thu, 28 Jan 2010 21:38:12 +0000

2 Jahre ist es jetzt in etwa her, dass ich einen Artikel über Eigene Templates in Trac geschrieben habe. Seitdem ist ein wenig passiert. Diesen Änderungen möchte ich hiermit Rechnung tragen. Ich habe das ganze Trac-Themes genannt, weil es weniger um Templating an sich gehen soll, sondern eher um eine Möglichkeit gemeinsame Styles festlegen zu können.

Leider ist es mit Trac immer noch nicht möglich unter einem Environment mehrere Projekte bzw. Repositories laufen zu lassen. Darum wird für jedes Projekt eine eigene Trac-Umgebung angelegt. Wichtig hierbei ist insbesondere für Firmen, dass alle Projekte zumindest in der Grundstruktur gleich aussehen und die Firmenfarben tragen.

“… was bisher geschah”

Wer zuerst probieren will, wie und was er alles anpassen kann, sollte sich das Verzeichnis templates unterhalb seiner Trac-Umgebung anschauen. Standardmäßig liegt dort die Datei site.html. Wenn man sie das erste Mal aufmacht, kommt sie sehr unscheinbar daher, denn wie man sieht, sieht man nichts. Nur einen html-Tag und ein paar unbekannt anmutende Python-Attribute.
Auf der Seite http://trac.edgewall.org/wiki/TracInterfaceCustomization ist glücklicherweise bereits ein Beispiel-Code für den Inhalt dieser Datei. Für jene, die gerne lieber mehrere Dateien nutzen wollen hier gleich die Anpassung mit Einbindung externer Dateien:



  
  
    ${select('*|comment()|text()')}
    
  

  
    
    
       
         
       
    

    ${select('*|text()')}

Interessanterweise funktioniert das einfache Anlegen einer site_header.cs und site_footer.cs nicht immer – bzw. bei mir hat das noch nie funktioniert -, wie es auf manchen Seiten beschrieben wird.
Mit diesem Grundgerüst ausgestattet lässt sich schon anfangen herumzuspielen. Für weiterführende Informationen zu Genshi und Clearsilver – den Engines im Hintergrund – sei auf folgende Seiten verwiesen:

Neue und alte Freunde

Ein altbekannter Helfer beim Erstellen von Templates ist auch in der Version 0.11.5 noch vorhanden. Der Konfigurationsparameter template_dir.

[inherit]
template_dir=

Mit diesem Parameter lässt sich das Verzeichnis für die Templates festlegen und wodurch verschiedene Seiten mit ein und demselben Template ausgestattet werden können.

Daneben ist ein neuer Freund dazugekommen der Parameter htdocs_location. Mit diesem Parameter werden alle internen URLs, die mit “common/” beginnen in die URL umgeschrieben, die als Wert angegeben wurde.

[trac]
htdocs_location=http://localhost/mytemplate

Führt, dazu, dass aus

folgendes wird

Achtung! Leider hat die Sache einen Haken. Eigene Links aus der site.html werden nicht übersetzt. Der folgende Code

${href.chrome('common/style.css')}

wird nur in "/trac/templating/chrome/common/style.css" umgewandelt, aber nicht weiter.

Wichtig ist außerdem zu beachten, dass htdocs_location nur für statische Inhalte, wie Bilder, JavaScript- und CSS-Dateien gedacht ist. Templates werden nicht automatisch von dort erkannt. Diese müssen explizit über template_dir konfiguriert werden. Leider ist es hier nur möglich lokale Verzeichnisse zu setzen. Wer z.B. versucht eine Internetadresse anzugeben, bekommt zwar keine Fehlermeldung, wird aber mit einem Standard-Template “belohnt”.

Abschließend möchte ich sagen, dass – gefühlt – wesentlich mehr über die trac.ini konfigurierbar ist, als es noch vor 2 Jahren der Fall war. Das macht definitiv Lust auf mehr, aber dennoch bleibt das ein oder andere noch zu tun.

Recipe: Apache 2 mit Tomcat 6 auf Ubuntu 9.10 für “Gourmets”

Rob — Sat, 23 Jan 2010 10:43:11 +0000

Das folgende Thema wurde schon an diversen Stellen mehr oder minder explizit beschrieben. Allerdings noch nicht aus meiner Sicht.

Was mir bei den meisten Howtos aufgefallen ist, dass sie schlechte Wartbarkeit hervorrufen und/oder irgendwas vergessen. Darum jetzt mein Versuch die Konfigurationsdateien der Welt unlesbar zu machen.

Die “Speisekarte” oder “Was will ich eigentlich”?

Tja. Für den einen oder anderen gezielten Sucher ist das schon klar, aber nochmal kurz für jene, die nur zufällig hier sind. Ich möchte in meiner URL nicht mehr http://localhost:8080 eingeben müssen um auf meinen Tomcat zu gelangen, sondern nur noch sowas wie http://tomcat.localhost. Ich hätte jetzt auch sagen können http://localhost, aber das wäre gelogen.

Installation der einzelnen Komponenten

Für die Installation nehme man eine Maus, Synaptic Paketverwaltung und zwei aussagekräftige Suchbegriffe wie tomcat6 und apache2. Für die Verknüpfung der beiden ist dann noch das Paket libapache2-mod-jk notwendig. Man würze das ganze mit einer Prise “Anwenden” und violá Apache 2 und Tomcat 6 sind installiert. Auf zu Schritt 2: die Dateien.

Die Dateien

Nichts läuft ohne eine anständige Konfiguration. Zur Vorbereitung lege man sich im Editor seiner Wahl folgende Dateien zurecht. Am besten mit sudo öffnen um darauf auch Schreibrechte zu haben.

/etc/apache2/sites-available/default
/etc/apache2/sites-available/mod_jk_vhosts
/etc/apache2/mods-available/jk.conf
/etc/apache2/workers.properties
/etc/tomcat6/server.xml
/etc/hosts

Die Dateien mod_jk_vhosts, jk.conf und workers.properties existieren höchstwahrscheinlich noch nicht. Darum diese bitte selbst anlegen.

Soweit diese “Vorspeise” abgeschlossen ist, wollen wir uns dem “Hauptgang” widmen: der Konfiguration

Die Konfiguration

Für die Konfiguration gehe ich jede der oben genannten Dateien einzeln durch und stelle eine mögliche Konfiguration vor. Diese Konfigurationen sind nur auf das notwendigste beschränkt. Falls weitere Optionen oder Alternativen notwendig sind, verweise ich gerne auf die entsprechenden Fachseiten.

mod_jk_vhost

Beginnen möchte ich mit der mod_jk_vhosts, da diese am umfangreichsten ist. Ich präsentiere … den Inhalt:

ServerName localhost
# NameVirtualHost *:80

	ServerName 127.0.0.2
	ServerAlias tomcat.localhost
	ServerAlias www.tomcat.localhost
	ServerAdmin webmaster@tomcat.localhost
	#Take note of the jsp content directory placement
	DocumentRoot /var/lib/tomcat6/webapps/
	
		Options Indexes FollowSymLinks +Includes
		AllowOverride All
		# DirectoryIndex index.jsp
	
	#Mount the folders with jsp pages
	JkMount /* worker1



	ServerName 127.0.0.3
	ServerAlias apache.localhost
	ServerAlias www.apache.localhost
	ServerAdmin webmaster@apache.localhost

	DocumentRoot /var/www
	
		Options FollowSymLinks
		AllowOverride None
	
	
		Options Indexes FollowSymLinks MultiViews
		AllowOverride None
		Order allow,deny
		allow from all
	

	ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
	
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
	

	ErrorLog /var/log/apache2/error.log

	# Possible values include: debug, info, notice, warn, error, crit,
	# alert, emerg.
	LogLevel warn

	CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"
    
	Options Indexes MultiViews FollowSymLinks
	AllowOverride None
	Order deny,allow
	Deny from all
	Allow from 127.0.0.0/255.0.0.0 ::1/128

Diese Datei wird anstelle der /etc/apache2/sites-available/default zukünftig für die Konfiguration des Apaches verwendet. Darum enthält sie auch große Teile der Original-Datei. Wenn der Inhalt der default-Datei anders aussieht, einfach den unteren Teil der mod_jk_vhosts-Datei mit dem Inhalt der default-Konfiguration abgleichen.

Zur Aktivierung der alternativen Konfiguration in der Konsole folgende Zeile ausführen:

sudo a2ensite mod_jk_vhosts

jk.conf

Die zweite Datei der ich mich widmen will, ist die jk.conf. Wie bereits erwähnt: sollte diese Datei noch nicht existieren, einfach unter dem oben genannten Pfad mit folgendem Inhalt speichern.

JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info

Die Konfiguration ist sehr minimalistisch. Mehr wird auch erstmal nicht benötigt. Es wird nur die Stelle für die Konfigurationsdatei angegeben, die Apache braucht um mit dem Tomcat zu sprechen und die Logging-Konfiguration, für den Fall, dass etwas schief läuft.
Damit diese Konfiguration auch berücksichtigt wird muss sie mit

sudo ln -s /etc/apache2/mods-available/jk.conf /etc/apache2/mods-enabled/

verlinkt werden.

workers.properties

Die workers.properties kann man als das Herzstück der Konfiguration bezeichnen, da sie die eigentliche Kommunikation zwischen Apache und Tomcat ermöglicht.

workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/java-6-sun
ps=/
worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

Der Kürze halber will ich an dieser Stelle nicht die einzelnen Parameter erklären, sondern nur auf die offizielle Dokumentation verweisen.

server.xml

Als dritte Datei kommen wir zur /etc/tomcat6/server.xml. Diese enthält die allgemeine Server-Konfiguration für den integrierten Tomcat von Ubuntu. An dieser Datei müssen zwei Änderungen durchgeführt werden:

Aktivierung von Port 8009 und
Server-Aliase für unseren VirtualHost setzen.

Für 1. einfach nach port="8009" suchen und die Zeile auskommentieren, sodass es in etwa so aussieht

...


...

Die Server-Aliase werden im Abschnitt Host eingetragen.

...

  ...
  www.tomcat.localhost
  tomcat.localhost
  127.0.0.2
  tomcat.localhost

...

`/etc/hosts`

Als letzten Schritt soll auch Ubuntu erfahren zu welchem Servernamen welche IP gehört. Darum in die /etc/hosts folgende Zeilen hinzufügen:

127.0.0.2 tomcat.localhost www.tomcat.localhost
127.0.0.3 apache.localhost www.apache.localhost

Das “Dessert”

Auf das Dessert freut man sich ja eigentlich am meisten. So auch hier. Nachdem alles konfiguriert wurde, einfach den Tomcat und den Apache neustarten:

sudo /etc/init.d/tomcat6 restart
sudo /etc/init.d/apache2 restart

Violá, wir sind finis … zumindest was meinen Versuchsaufbau angeht. Falls noch alles läuft, habe ich was falsch gemacht. Im Ernst: Falls Kommentare sind, weil etwas nicht funktioniert bitte ich um User-generierten Content

Joda – “Bis 900 Jahre, wirst aussehen du nicht gut!”

Rob — Tue, 15 Dec 2009 09:45:34 +0000

Mit diesen Worten hat Yoda in Starwars nicht nur eine der traurigsten Szenen aufgelockert, sondern auch gleich – unbeabsichtigt – ein Grundproblem der Javawelt adressiert. Die API für die Zeitverwaltung.

Wann wenn nicht jetzt?

Beim Stöbern in Quellcode bin ich letztens wiedermal über eine lustige Zeile gestoßen:

...
System.currentTimeInMillis() //we can get the time in milliseconds after 1 Jan 1970 at 0:00:00am GMT
...

Auf den ersten Blick harmlos. Was soll da schon passieren? Ich will die Frage umformulieren: Was passiert danach? Mit dem Wert wird in der Regel angefangen zu arbeiten. D.h. Tage werden hinzugefügt, abgezogen um z.B. Startzeitpunkte zu ermitteln. Dabei wurde in dem Code, den ich gesehen habe in etwa folgendes gemacht:

final long now = System.currentTimeInMillis();
final long oneDay = 1000 * 60 * 60 * 24;
final long tomorrow = now + oneDay;
...

Sieht immer noch alles harmlos aus? Dann weiter …

Ein Tag hat 24 Stunden

An einer anderen Stelle wurde ein Vergleich zweier Daten durchgeführt. Hier die anonymisierte Fassung:

final long oneDay = 1000 * 60 * 60 * 24;

final Calendar calendar = Calendar.getInstance();
calendar.set(2009, 9, 24, 10, 0);
final long summerTime = calendar.getTimeInMillis();

final Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.set(2009, 9, 26, 10, 0);
final long winterTime = comparisonCalendar.getTimeInMillis();

final long difference = winterTime - summerTime;

if (difference == 2 * oneDay) {
    ...
}

Immer noch harmlos? Der ein oder andere wird jetzt sagen: klar. Leider steckt der Teufel im Detail. Was meistens vernachlässigt wird ist die europäische (Un)Sitte zwischen Sommer- und Winterzeit zu wechseln oder auch ganz allgemein alle 4 Jahre mal einen Tag im Februar mehr einzuplanen. Hier muss sich dieser Ansatz leider geschlagen geben.

Ich muss mich an dieser Stelle entschuldigen, denn ich habe den Code bereits so abgeändert, dass das Problem der Sommer- und Winterzeit offensichtlich wird. Der Originalcode sieht natürlich etwas anders aus. Aber nun sollte definitiv ersichtlich werden, warum das nicht funktionieren kann. Hier wird mit festen Zeitintervallen (oneDay) gearbeitet. Leider hat der Tag zum Zeitwechsel nicht 24, sondern entweder 23 oder 25 Stunden.

Geht man mit Java-Hausmitteln an dieses Problem landet man dann aber auch schnell in Code-Schnippseln wie dem Folgenden:

...
Calendar calendar = Calendar.getInstance();
Date now = calendar.getTime();
calendar.add(Calendar.HOUR_OF_DAY, 1);

...

oder die Alternative für den Vergleichscode:

...
Calendar calendar = Calendar.getInstance();
calendar.setTime(2009, 9, 24, 10, 0);
calendar.add(Calendar.HOUR_OF_DAY, 2);

Calendar comparisonCalendar = Calendar.getInstance();
comparisonCalendar.setTime(2009, 9, 26, 10, 0);
if (calendar.getTimeInMillis() == comparisonCalendar.getTimeInMillis()) {
...

Damit löst man zwar das Problem mit der Zeitumstellung, aber auf Dauer ist schön was anderes, denn ein weiterer Schwachpunkt der API, aus meiner Sicht, ist die schlechte Lesbarkeit. Denn wer sieht schon auf den ersten Blick, dass hier nicht der September, sondern der Oktober gemeint ist. Ja, man kann auch mit den Calendar-Konstanten arbeiten, aber auch das führt eher zu unnötig langen Codezeilen.

… einer, der der Macht das Gleichgewicht bringen wird …

Eine elegante Lösung hierfür bietet – nein nicht Skywalker, sondern – die Joda-Bibliothek. Diese erlaubt es das Millisecond-Massaker zu umgehen und die Schwächen der Standard-API zu minimieren. So sieht der Code von oben mit Joda etwa so aus:

...
DateTime dt = new DateTime();
DateTime oneDayLater = dt.plusDays(1);
DateTime oneDayEarlier = dt.minusDays(1);
...

Auch Vergleiche wirken wesentlich angenehmer:

final DateTime now = new DateTime();
final DateTime before = now.minusDays(100);
final Days days = Days.daysBetween(before, now);
if (days.getDays() == 2) {
...

“Schneller, leichter, verführerischer”

Auch wenn das nur ein erster Blick auf Joda war, zeigt sich hier schon die Eleganz und Mächtigkeit dieser Bibliothek. Wer sich nicht scheut ein wenig englisch zu lesen, sei für weitere Informationen auf das IBM-Tutorial Joda-Time und die Website http://joda-time.sourceforge.net selbst verwiesen.

Ansonsten, sehen wir uns in 900 Jahren um Mitternacht

final LocalDate localDate = new LocalDate();
final DateTime then = localDate.toDateMidnight().toDateTime().plusYears(900);

Und plötzlich war alles dunkel …

Rob — Sat, 14 Nov 2009 09:40:03 +0000

Ich weiss nicht, was passiert ist, aber nach dem Upgrade von Ubuntu auf 9.10 wurden diverse Entwickler-Tools unbenutzbar. Dabei handelt es sich insbesondere um Anwendungen, die nicht direkt aus dem Ubuntu-Repository stammen. Im Folgenden will ich auf Eclipse und Trac eingehen.

Eclipse 3.5

Nachdem auf GTK+ 2.18 aktualisiert wurde, funktionieren diverse Buttons in Eclipse nicht mehr. Schnell wird man dank Google auf der Suche nach einem Fix bzw. Workaround fündig (Migrating to client-side windows). Offensichtlich ist die Umgebungsvariable GDK_NATIVE_WINDOWS für das Problem verantwortlich. Diese muss auf den Wert true gesetzt werden, damit SWT-basierte Java-Oberflächen (Anmerkung: auch andere Java-Applikationen mit SWT haben das Problem) wieder in altem Glanz erstrahlen.

#!/bin/bash
env GDK_NATIVE_WINDOWS=true /eclipse

(Den Pfad bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Leider ist dies nur ein bescheidener Workaround, denn sobald man Eclipse aus sich heraus neu startet (z.B. nach Upgrades oder Plugin-Installationen) existiert das alte Problem wieder. Genauso, wenn man den Workspace versucht zu wechseln, da sich Eclipse auch hier herunterfährt und neu startet.

Ein richtiger Fix ist für die Version 3.5.2 angedacht bzw. soll in der 3.6 schon integriert sein, welche für die SDK-Variante bereits existiert. Nur für JEE-Developer wird es wohl noch etwas dauern.

Von einem globalen Umsetzen der Variable GDK_NATIVE_WINDOWS wird an diversen Stellen explizit abgeraten. Hier sei aber anzumerken, dass die Eclipse-Installation aus den Ubuntu-Repositories genau das macht. Für alle, die etwas “wagemutiger” sind hier das Startskript mit export.

#!/bin/sh

# work around e#290395 / LP: #458703
export GDK_NATIVE_WINDOWS=true

xuldir=/usr/lib/xulrunner-$(/usr/bin/xulrunner-1.9.1 --gre-version)
LD_LIBRARY_PATH=$xuldir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} /eclipse
 "$@"

(Den Pfad bitte an das jeweilige Installationsverzeichnis von Eclipse anpassen.)

Dieses Skript am besten unter /usr/local/bin als eclipse ablegen und alle Links, die vorher direkt auf die Eclipse-Startdatei gegangen sind auf dieses Skript umbiegen.

Trac

Interessanterweise – was die primäre Motivation für diesen Kurzkommentar war – hat es auch das Bugtracking-Tool Trac erwischt. Zum Glück nicht so “heftig” wie Eclipse, aber dafür umso unverständlicher.

Ich habe lokal Trac mittels easy_install installiert gehabt. Nach dem Upgrade auf Ubuntu 9.10 erhielt ich plötzlich auf allen Trac-Seiten einen 500-Fehler. Nach kurzem Suchen fand ich in der error.log-Datei von Apache (Pfad unter Ubuntu: /var/log/apache2/error.log) folgenden Eintrag:

... [error] [client 127.0.0.1] ImportError: No module named genshi, ...

Warum das Modul plötzlich nicht mehr vorhanden war kann ich zum aktuellen Zeitpunkt nicht erklären, aber das war noch nicht das Ende.

Just in dem Moment wo ich mit

sudo easy_install Genshi

das entsprechende Modul installieren wollte, quittierte mir Ubuntu die Nachricht, dass easy_install nicht existiert. Ein kurzer Blick in Synaptic unter python-setuptools bestätigte die Vermutung, dass das Paket nicht installiert war. Ich möchte an dieser Stelle nicht ausschließen, dass es beim Upgrade in der Liste der zu deinstallierenden Pakete dabei war, aber dennoch ärgerlich. Also war auch hier nachinstallieren angesagt.

Zum Glück fügte sich dann alles sehr schnell. Das Genshi-Modul installierte sich ohne Probleme.

Abschließend musste noch der Workaround für einen Bug (http://trac.edgewall.org/ticket/7526) eingebaut werden. Einfach die compat.py im functional/tests-Ordner in testcompat.py
umbenennen und die compat.pyc in compat.pyc.old umbenennen oder gleich löschen.

Blog redesigned … to be continued

Rob — Sun, 08 Nov 2009 07:04:36 +0000

Wartungsarbeiten sind Arbeiten, die ungnädig und ewig warten, bis man sie macht. So geschehen mit diesem Blog und demnächst auch mit der Webseite http://www.pincservices.de.

Da der Blog seit einiger Zeit Brach lag, musste eine Runderneuerung her. Nachdem die Software auf den aktuellen Stand gebracht wurde, fiel mein Augenmerk auf das Frontend. Ich weiss gar nicht mehr wie viele Jahre das alte Frontend ausgehalten hat, aber ich entschuldige mich hiermit nachdrücklich bei allen, die darunter leiden mussten.
Seit heute morgen erstrahlt der Blog in neuem Gewand und auch die Nutzbarkeit ist – nach eigenen Erfahrungen – erheblich gestiegen. Nebenbei sind diverse “Gimmicks” ins Template geflossen, wobei ich nicht verrate welche.

Dennoch stehen – jetzt, wo man alles lesen kann – die nächsten Umbauten an. Mit der Aktualisierung sind einige Probleme beim Encoding aufgetreten und einige Artikel müssen nochmal visuell nachgebessert werden. Ausserdem fehlen noch einige Zutaten zum “perfekten Glück”.

Ich werd mich dann mal weiter darum kümmern – Also viel Spaß beim stöbern.

Webapps become wicket …

Rob — Sat, 26 Sep 2009 00:59:55 +0000

Im Allgemeinen sprießen Webframeworks wie Pilze aus dem Boden. Mal mehr und mal weniger erfolgreich. Allerdings haben die meisten immer den gleichen MVC-Ansatz. Daten werden im Model vorgehalten, der Controller kümmert sich um die Bereitstellung der Objekte und der Navigation und das View “holt” sich alles was es braucht aus dem Kontext. D.h. man hat häufig eine Mischung aus HTML und einer expliziten Expression Language im View (z.B. JSTL).
Der große Nachteil bei dieser Form von Aufteilung ist, dass man beim Testen häufig auf verschiedene Frameworks zurückgreifen muss um die Korrektheit der Anzeige zu gewährleisten bzw. stark auf manuelles Testen angewiesen ist. Im Speziellen sei hier die Problematik von Text-Lokalisierung erwähnt, die jedem Entwickler im Laufe seiner Arbeit schonmal “auf die Füße gefallen” sein wird.

Einen etwas anderen Ansatz verfolgt an dieser Stelle das Framework Wicket. Hier wird bewusst auf eine explizite Expression Language verzichtet – soweit ich sehen kann. Alle Referenzen zwischen Controller und View werden über eine Wicket-Id-Tag () aufgelöst. Damit steht zwar der Controller in der Pflicht alle Inhalte entsprechend umfangreicher aufzubereiten (z.B. explizite Änderungs-Propagierung), aber diese Vorgehensweise hat den elementaren Vorteil, dass Seiten wesentlich einfacher auch mit z.B. Junit-Tests geprüft werden können.

Es wäre alles zu schön um wahr zu sein, wenn es nicht schon auf den/meinen ersten Blick ein kleines Problem gäbe. Natürlich geht Wicket von einem MVC-Ansatz aus und benötigt damit HTML-Dateien zum Rendern. Leider wird standardmäßig davon ausgegangen, dass die HTML-Dateien im gleichen Verzeichnis liegen wie die entsprechende Klasse.

“First we need to create a web page. Wicket has a WebPage class suited for this task. All webpages need to be subclasses of WebPage. Another requirement is that the actual HTML file and the class name are equal: Index.html and Index, IndexPage.html and IndexPage or HelloWorld.html and HelloWorld. They also need to be in the same place on the classpath. The best way to develop is to put them in the same directory. This might seem strange in the beginning, especially when you are accustomed to separate html files and java files. However, since all pages are actually just components, it makes perfect sense in terms of reusability.”

(siehe hierzu http://cwiki.apache.org/WICKET/newuserguide.html#Newuserguide-TheHTML)

Für jeden Webentwickler, der es gewohnt ist, dass HTML- respektive JSP(X)-Dateien gefälligst weit weg von den Klassen zu liegen haben, eine Umstellung die nur leidlich zu ertragen ist.
Zum Glück haben die Wicket-Entwickler hier aber ein Einsehen und bieten in der Referenz-Dokumentation auch gleich mehrere Lösungen an, wobei aus meiner Sicht, die Maven-Lösung zu empfehlen ist, da sie versionsunabhängig ist.

GIT geht nicht gern mit Fremden: *** Please tell me who you are.

Rob — Sat, 15 Aug 2009 18:18:50 +0000

Für alle, die es leid waren, sich mit Subversion herumzuschlagen – oder einfach mal neugierig auf ein anderes Versionssystem sind, haben bestimmt schonmal etwas von GIT gehört.

Ich will an dieser Stelle weder die üblichen Lobeshymnen, noch die allseitsbeliebten Hasstiraden anstimmen, sondern nur eine kleine Hilfestellung geben, wenn man sich dazu entschließen will das GIT-Plugin von Hudson zu nutzen.

Die Installation ist zwar – wie immer – simpel, aber leider mag Hudson evtl. nicht gleich mit GIT “spielen”. Will man den Job starten kommt relativ schnell folgende Ausgabe in der Konsolenansicht.

Gestartet durch Benutzer anonymous
Checkout:workspace / /usr/local/apps/hudson_home/jobs/gitTest/workspace – hudson.remoting.LocalChannel@1063971
Last Build : #2
Checkout:workspace / /usr/local/apps/hudson_home/jobs/gitTest/workspace – hudson.remoting.LocalChannel@1063971
Fetching changes from the remote Git repository
Fetching upstream changes from file:///var/local/workspaces/experiments/sampleProject
[workspace] $ git fetch file:///var/local/workspaces/experiments/sampleProject +refs/heads/*:refs/remotes/origin/*
[workspace] $ git ls-tree HEAD
Seen branch in repository origin/master
Commencing build of Revision f7dc0e95f48a084d5192c3712f14b3353a98a876 (origin/master )
Checking out Revision f7dc0e95f48a084d5192c3712f14b3353a98a876 (origin/master )
[workspace] $ git checkout -f f7dc0e95f48a084d5192c3712f14b3353a98a876
[workspace] $ git tag -a -f -m “Hudson Build #3″ hudson-gitTest-3
FATAL: Could not apply tag hudson-gitTest-3
hudson.plugins.git.GitException: Could not apply tag hudson-gitTest-3
at hudson.plugins.git.GitAPI.tag(GitAPI.java:265)

[haufenweise stacktrace]

… 12 more
Caused by: hudson.plugins.git.GitException: Command returned status code 128:
*** Please tell me who you are.

Run

git config –global user.email “you@example.com”
git config –global user.name “Your Name”

to set your account’s default identity.
Omit –global to set the identity only in this repository.

fatal: empty ident not allowed

at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:297)
… 14 more

Offensichtlich ist GIT ein wenig schüchtern und mag nicht jeden an die digitale Wäsche ranlassen.

Leider findet man nicht wirklich eine Möglichkeit Hudson eine eigene Identität via Webfrontend zu geben. Der Trick liegt genau dahinter – und zwar im Dateisystem.

Genauer gesagt in der /etc/passwd. Aus irgendwelchen Gründen brauch GIT hier einen Eintrag im Feld für den fullName. Unter Ubuntu hat der Tomcat-User dort standardmäßig nichts gesetzt. Fügt man jetzt dort einfach ‘Tomcat 6,,,’ ein, läuft es auch mit dem CI-Nachbarn.

Alle, die sich über die Gründe Gedanken machen, seien auf die Git FAQs verwiesen.

So dann – viel Spaß beim Bauen.

Hudson und Grails am heimischen Herd

Rob — Wed, 12 Aug 2009 22:01:52 +0000

Nachdem sich verschiedene Projekte bei mir angesammelt haben und ich für jedes in der Regel ein entsprechendes Trac-Projekt angelegt habe, fehlte mir immer mehr die projektübergreifende Oberfläche.

Mit den Wochen und Monaten schwängerte sich mein Geist mit dem Gedanken sich an Trac “zu vergreifen” und selbst so eine Oberfläche zu schreiben. Zum Glück kam mir eine neue Anforderung in den Weg, die mir die Arbeit teilweise abnahm: der Wunsch eines Continuous Integration Systems – kurz CI.

Da ich schon gute Erfahrungen mit Hudson gemacht hatte, war die Entscheidung schnell getroffen das System auch für mich einzusetzen. Die Vorteile:

einfache Installation
Open Source
kostenfrei

Allerdings musste gewährleistet werden, dass man damit Grails-Projekte bauen kann. Schaut man in die Plugin-Liste schreit es einen förmlich an: “Hier bin ich. Ist total easy-schneasy. Machs einfach!”

Aber wie so oft bei so offensichtlichen Aktionen liegt die Tücke im Detail. Leider hören – wie so oft – die Tutorials im Netz bei der Hälfte auf und vermitteln einem das Gefühl, dass man zu doof für die IT-Welt ist. Deshalb möchte ich hier einfach meine Erfahrungen bei der Einrichtung von Hudson mit den Grails- und Trac-Plugin auf einem Ubuntu-System vorstellen.

System

Ubuntu 09.04
Tomcat 6 (aus den Ubuntu-Repository)
Trac (manuell installiert)
Grails 1.1.1

Anmerkung
Ob Trac jetzt manuell oder aus dem Repository installiert wurde, ist eigentlich egal.

Hudson

Als erstes ging es darum Hudson zu installieren. Zwar bietet Ubuntu auch hier an über eine kleine Erweiterung der Repositories Hudson als Daemon zu installieren, allerdings bin ich persönlich kein großer Freund davon. Deshalb Alternative: war-File downloaden und einfach im Tomcat deployen.

Achtung!!! Wenn man das macht, sollte man vorsichtig beim Neustart aus Hudson heraus sein. Die Applikation fährt interessanterweise den Tomcat runter, bekommt ihn aber danach nicht mehr gestartet.

Zwei Dinge muss man dabei beachten, die aber auch auf der Hudson-Seite dokumentiert sind.

die Variable HUDSON_HOME muss gesetzt sein – habe ich bei mir direkt in das Tomcat-Startskript geschrieben (Faulheit siegt)
Es müssen teilweise noch Verzeichnis-Rechte angepasst werden, damit Hudson korrekt läuft

Nachdem Hudson nun endlich sein Pracht im Browser präsentiert geht es weiter mit dem Grails-Plugin.

Grails

Die Installation von Plugins ist in Hudson sehr simpel – oder wie manch Web 2.0-Entwickler sagen würde: “kissy” (von KISS – Keep it stupid simple). Einfach Häkchen setzen und auf “Installieren” klicken. Wie schon erwähnt, kann es hierbei dazu kommen, dass Hudson den kompletten Tomcat versucht neu zu starten, was zumindest bei mir nicht funktioniert hat. Ggf. einfach den Tomcat manuell neu starten.

Nachdem das Plugin installiert ist, müssen noch einige Konfigurationen durchgeführt werden. Als erstes muss der “Grails Builder” in der globalen Konfiguration von Hudson angelegt werden. Hier kann man verschiedene Grails-Installationen angeben, was insbesondere durch die teilweise Inkompatibilität der Versionen von großem Vorteil ist. Da die Sache in zwei Textboxen geregelt wird, verzichte ich mal auf den obligatorischen Screenshot.
Hat man jetzt die notwendigen Installationen angegeben kann man sich gütlich an die Konfiguration des Jobs machen. Hier muss ich vorausschicken, dass ich bereits einige Jobs angelegt hatte.

Unter dem Punkt “Build Verfahren” kann man über den Button “Build-Schritt hinzufügen” ein “Build with Grails” anlegen. Dabei lassen sich verschieden Werte konfigurieren. Nach einigem Herumprobieren waren aber nur drei relevant:

Grails Installation (wurde eben in der globalen Konfiguration angelegt)
Targets
grails.work.dir

Die Targets kann sich jeder selbst aussuchen aus der Liste, die “grails help” ausgibt. Bei mir sind das "test-app -unit --non-interactive" war doc.
Wichtig ist allerdings vor allem der Parameter grails.work.dir!

Das Grails-Plugin erwartet standardmäßig, dass es Zugriff auf das Verzeichnis /usr/share/tomcat6/.grails besitzt um auf den scriptCache zugreifen zu können. Da dieses Verzeichnis aber nicht zwingend freigegeben werden soll, muss ein alternatives Verzeichnis über grails.work.dir gesetzt werden. Andernfalls müssen die Zugriffsrechte mittels sudo chmod -R 777 /usr/share/tomcat6/.grails gesetzt werden.
Das Projekt-Verzeichnis hat noch eine weitere Bedeutung. Wenn man z.B. in Subversion seinen Code unter “trunk” eincheckt und keinen expliziten Modulpfad angelegt hat, wird automatisch trunk als Projektname auch in Hudson beim Bauen verwendet. Nun kann man sich vorstellen, dass bei mehreren Projekten, die alle in “trunk” liegen dies zu einer Überschneidung führt, die nicht unbedingt erwünscht ist.

Nichtsdestotrotz, bin ich hiermit bereits an das Ende meiner Vorstellung gekommen. Nach der Konfiguration des Jobs einfach auf “Jetzt bauen” klicken und schauen was passiert – ich hoffe mal es funktioniert. Ansonsten: bitte nicht hauen, bei mir läufts

Trac

Für alle, die jetzt fragend dastehen und wissen wollen: “aber er hat doch was von Trac erzählt”. Ja, das habe ich und ja, auch das geht sehr einfach. Nachdem man das Trac-Plugin installiert hat, erscheint ein Eingabefeld in der Job-Konfiguration, in dem man einen Link zum Trac-Projekt hinterlegen. Nachdem man diesen gespeichert hat, erscheint ein simpler Menüpunkt auf der Job-Seite “Trac”, der zu der entsprechenden Trac-Seite führt.

Groovy: copy as

Rob — Mon, 13 Jul 2009 22:02:02 +0000

Ohne viel Geschwafel will ich einfach mal ein kleines Script vorstellen, mit dem sich das Kopieren auf der Konsole etwas lesbarer gestalten lässt.
Der Aufruf kann wie folgt aussehen: copy testFile to ../ as testFile2
Dabei wird die Datei testFile in das Elternverzeichnis kopiert und in testFile2 umbenannt.

Skript zum Download