Das Internationalisierungsprinzip von GWT ist an sich sehr einfach. Man nehme ein paar properties-Dateien, inkludiere das I18N-Modul und lasse sich die entsprechende Java-Datei generieren. Soweit so gut. Leider nicht so, wenn man den UIBinder verwenden möchte. Hier haben sich bereits diverse verzweifelte Entwickler einen “abgebrochen” um herauszufinden, welche Dateien an welcher Stelle liegen müssen, damit man in den jeweiligen ui.xml-Dateien eine vernünftige Übersetzung erhält.

Grundsätzlich gilt, dass Übersetzungs-Keys aus ui.xml-Dateien immer im Package com.google.gwt.i18n.client mit dem Namen LocalizableResource_[locale].properties liegen müssen. Diesen Umstand verdanken wir dem MessagesWriter, der vom UiBinderGenerator herangezogen wird. Dieser generiert zwar die Messages-Dateien für alle Keys, die sich in einer ui.xml-Datei befinden in eine eigene Messages-Klasse, importiert aber mittels

writer.write("import static com.google.gwt.i18n.client.LocalizableResource.*;");

ausschließlich die Übersetzungen aus LocalizableResource. Soweit so gut, möchte man meinen. Problematisch wird es dann, wenn man Übersetzungen sowohl im Java-Code, als auch im in den ui-Dateien haben will. Typisches Beispiel sind hier Tabellen vom Typ CellTable, deren Spalten normalerweise in den View-Klassen definiert werden. Will man hier nun sprachlich angepasste Spaltenköpfe haben, muss man diese mittels einer Messages-Klasse übersetzen.
In diesem Moment steht man vor der Frage: Möchte ich zwei Übersetzungsdateien verwalten, in denen ggf. Keys doppelt auftreten, oder möchte ich nur Eine für beide Mechanismen haben?

Ohne auf die unsäglichen und teilweise unpraktikablen Varianten einzugehen, die sich im Netz bereits befinden bzw. die kryptisch auf der GWT-Dokumentation vorgestellt wurde, stelle ich hier meine zwei Lösungen vor, die ich für sinnvoll erachte.

Variante 1: ui:with

Die klassische Variante. Man nehme einfach die existierenden Messages und importiere sie wie folgt in die ui.xml-Datei.

 <ui:with field='messages' type='com.my.app.MyMessages'/>
 <g:Label text="{messages.hello}" />

Diese Variante hat den Vorteil, dass man auf die komplette Bandbreite der Erweiterungen, die für Messages-Klassen bereitgestellt wurde zugreifen kann.

Variante 2: Customized Messages-Interface

In Variante 1 nutzen wir den Mechanismus, der eigentlich für den Java-Code gedacht war für den UiBinder. Natürlich geht es auch anders herum. Wir “kopieren” einfach den Mechanismus der MessagesWriter-Klasse. Wir bauen uns ein Interface und importieren die LocalizableResources.

package com.mypackage;

import static com.google.gwt.i18n.client.LocalizableResource.*;

public interface MyAppMessages extends Messages {
  @DefaultMessage("Example")
  String example();
}

Der GWT-Compiler greift hier einfach das Interface und verknüpft die Methoden mit den Keys aus der jeweiligen LocalizableResource-Datei. Damit lassen sich auch innerhalb von Java-Dateien die Keys aus LocalizableResource verwenden.

Achtung:
Leider gibt es nicht die Möglichkeit LocalizableResource-Dateien über den i18n-Aufruf in eine Klasse übersetzen zu lassen, da LocalizableResource bereits ein existierendes Interface ist und die Übersetzung zu einer sogenannten zyklischen Vererbung führt.

Fazit

Mit beiden Varianten lässt sich das bestehende Problem lösen, dass man nur einen Mechanismus zur Internationalisierung innerhalb von GWT-Projekten nutzen möchte. Welche der beiden zum Einsatz kommt hängt stark von der bestehenden Struktur und – was nicht zur vernachlässigen ist – von der Motivation des Entwicklers, welche Schritte für ihn in seinem Arbeitsprozess besser integriert werden können, ab. Während Variante 1 den Aufruf des i18n-Creators erfordert, muss in Variante 2 das Interface immer manuell angepasst werden.

So schlimm ist die Welt der Software-Entwicklung nun zwar auch nicht, dass man blindlinks irgendwo im Dunkeln rumdüst und völlig überraschend in einer Raumzeit-Anomalie hängt oder von Q für die Verbrechen der Menschheit angeklagt wird.
Aber gerade bei neuen Software-System hat man viele Stellen noch nicht berührt und muss sich häufig auf bereits existierendes Verhalten verlassen, wenn man neue Komponenten integriert. So geschehen heute. Ich möchte kurz vorstellen – die Aufgabe:

Rufe via REST eine URL auf, die den Status einer Entity umsetzt.

Zusätzliche Herausforderung:

Kann sein, dass die Gegenstelle nicht da ist.

Es folgte eine Odyssee von URL-Anpassungen. So mach ich mich daran, den Aufruf zu implementieren und bekomme ein einziges Wort zurück “StatusNotAllowedException“. Ich denk mir so: “Ok, das hört sich doch gut an.”, da ich wusste, dass die Status-Änderung mit dem aktuellen Objekt wirklich nicht erlaubt bzw. sein sollte. Witzigerweise war aber das Problem, dass ich einen völlig falschen Call getriggert hatte – klassisch Copy&Paste. Erst nachdem ich verkündete, dass der Aufruf implementiert sei, wurde ich aufgeklärt, dass die Antwort nicht korrekt ist. Nach kurzem scharfen Hinsehen war die URL dann auch schnell ausgetauscht.

Also ging es auf zu Runde 2. Wie bereits angesprochen gab es ja noch die Nebeninfo, dass evtl. die Empfängerstelle noch nicht implementiert ist. Darum gab es auch hier wieder für mich keinen wirklichen Argwohn als die Schnittstelle eine 404 zurücklieferte. Vorgewärmt von der ersten Fehlermeldung hab ich gleich gefragt, ob die Empfängerseite wirklich nicht da sei, worauf ein “doch, ist da” zurückgeliefert wurde.
Also schauen wir uns die URL an und entdecken: Oha, die Ports sind falsch. Aber nicht nur bei einer URL, sondern bei allen. Auch das geändert und somit kommen wir zu …

… Runde 3: Fehlermeldungen, die nicht da auftauchen wo sie erwartet werden. Leider gab es dann noch einen Schusselfehler bei der Änderung der Ports, so dass ein Aufruf an den alten Port geschickt wurde und mit unverhohlener Freundlichkeit meinte “kenn ich nicht”. In meinem Gesicht manifestierte sich die Frage “was kennst du nicht?”. In meinem Log tauchte nichts auf, im Log auf dem Server, auf dem wir dachten, dass der Aufruf aufschlagen sollte kam auch nichts. Zwar lag das eigentliche Problem am falschen Port, aber die Fehlermeldung sagte nichts darüber aus, was gerade schief gelaufen ist. Auch im Log des eigentlichen Servers – da wo der Call gelandet war – stand nichts aussagekräftiges. Am Ende half nur das 4-Augen-Prinzip um den Fehler zu finden.

Fazit: Ein Hoch auf die verbale Kommunikation und ein leidiges Buh auf schlecht formulierte Fehlermeldungen. Zwar muss man schon einiges an Schusseligkeit an den Tag legen um so viele Fehler hintereinander zu machen – und es passiert doch – aber gerade beim Ersten hätte es beinahe dazu geführt, dass ich mich in einer Sicherheit wähnte, die gar nicht da war und die uns im Produktiv-System ggf. teuer hätte zu stehen kommen können. Darum sollten Fehlermeldungen stets so viel Informationen enthalten, dass sie das eigentliche Problem konkret darstellen und entweder mögliche Ursachen oder mögliche Lösungen vorschlagen.

Aber bevor ich in einen Rausch von Anschuldigungen, Verfluchungen und verzweifelten Rundumschlägen verfalle – eine kurze Vorstellung von dem was agile Softwareentwicklung leisten soll.
Wikipedia beschreibt die Zielsetzung von agiler Softwareentwicklung wie folgt:

Das Ziel Agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell.

Häufig wird sich vor allem auf die ersten beiden Sätze konzentriert, die selbstverständlich eine große Bedeutung haben. Aber aus meiner Sicht hat aber der letzte Satz eine interessante Nebenbedeutung.
Im Folgenden werde ich mich auf die Vorgehensweise nach Scrum konzentrieren, da sie meist als Vorzeige-Prozess verwendet wird und sich viele Firmen dies auf die “Fahnen” schreiben.
Agile Softwarentwicklung wird als Gegenbewegung zu bürokratischen Prozessen angesehen. Was hier nur häufig scheinbar hinzugefügt wird, ist das Abschaffen von (notwendigen) formalen Regeln.

• So ignoriert man des öfteren, dass ein Sprint in sich unveränderbar ist – das dies auch legitim sein kann, werde ich gleich erläutern.
• Daily Scrums z.B. werden teilweise wie ein Kaffeeklatsch behandelt oder – noch schlimmer – werden als Plattform für das Management verwendet um dem Team neue Priorisierungen mitzuteilen.
• Beliebt sind auch Sprintplanungen, in denen dem Team vorgeschrieben wird, wieviel Zeit es für welche Aufgaben haben darf.
• Teammitglieder erscheinen gar nicht oder zu spät zu Meetings.
• Daily Scrums beinhalten entweder zu viele oder zu wenige “Pigs” bzw. “Chickens” verhalten sich wie “Pigs”.
• Sprintziele bzw. Commitments werden nicht ernst genommen.
• …

Eine kleine Übersicht über Anhaltspunkte, dass es mit dem agilen Prozess nicht ganz so gut bestellt ist, gibt folgende Seite über Scrum-Smells.

Die Konsequenzen, wenn der “Gestank” (dt. für Smell) nicht berücksichtigt wird, sind einerseits lange Entwicklungszeiten und häufige Wartungsaktionen, da die Anforderungen nicht klar waren/sind oder Aufgaben permanent verschoben werden und andererseits Versuche Probleme mit klassisch bürokratischen Mitteln zu kompensieren, wie minutiös ausgearbeiteten Konzepten. Dadurch verlangsamt sich zusehends und dramatisch die Entwicklungszeit und damit die Reaktionszeit auf Kundenwünsche und Bugs. Ebenso wird die Flexibilität des Teams auf die reine Programmierung reduziert, die dann ggf. noch durch (von sich selbst übermäßig überzeugte) Code-Reviewer ad absurdum geführt wird.

Da dies kein komplettes Buch über die Vor- und Nachteile von Scrum respektive agiler Softwareentwicklung werden soll, möchte ich nur Folgendes festhalten:

Agile Softwareentwicklung besitzt genausoviel oder teils sogar mehr Formalismus als klassische Softwareentwicklung. Allerdings wird versucht den bürokratischen Aufwand zu reduzieren. Agil heisst hier vor allem, dass das Team wesentlich flexibler agieren und reagieren kann, als es in klassischen Prozessen ist und nicht, dass die Aufgabenstellung beliebig agil geändert werden kann. Dieser erhöhte Formalismus bedarf aber ebenso einer durchgängigen Disziplin aller Beteiligten. Ist diese Disziplin gegeben lassen sich auch innerhalb einer Iteration die Anforderungen bis zu einem bestimmten Grad ändern. Falls nicht, ist davon – wie es im Allgemeinen in der Literatur vorgegeben ist – abzuraten.

Unter https://github.com/Zigu/PdfRenderer habe ich ein älteres Projekt von mir in ein neues “Misch-Gewand” geworfen und geschaut ob es funktioniert. Und ja, das tut es – mit Einschränkungen.

Grundsätzlich kann man sagen, dass die Kombination Maven2 + Java + Groovy eine sehr angenehme Sache ist, wenngleich der Weg dorthin etwas dornig war. Insbesondere durch die maßlos veraltete Dokumentation von GMaven – ich verzichte bewusst auf eine Verlinkung – wodurch nicht klar war, wie einfach es eigentlich ist Maven dazu zu bringen auch Groovy-Code zu verarbeiten.

Vorsicht ist allerdings geboten beim Einsatz von Closures in Vererbungshierarchien. Es gibt in Groovy 1.7.6 noch ein Problem, wenn eine konkrete Kindklasse aufgerufen wird, deren abstrakte Oberklasse ein Closure enthält, dass private Felder dieser Elternklasse verwendet. Eine kurze Skizzierung des Problems:

abstract class A {
  private List _myList;
  private ListElementHandler _handler;

  public void handleList() {
    _myList.each{ _handler.do_something_with(it) }
  }
}

class B extends A { ... }

class C {
  public void call() {
    def b = new B()
    b.handleList()
  }
}

Leider kommt es im Zuge des Abarbeitung der Klasse C zu einer Exception, dass das Feld _handler nicht zur Klasse B gehört. Dieses Problem ist bereits in den Groovy-Bugtracker aufgenommen worden.

Trotz dieser kleineren Hürden, verlief die Umstrukturierung ziemlich glatt und am Ende entstand größtenteils ein stimmiges Gesamtbild mit einigen sehr angenehmen “Abkürzungen” dank Groovy.

Nachdem ich bereits über einen Workaround für GWT 2.1 bezüglich des RequestFactory-Einsatzes mit Spring gesprochen habe war für mich vor allem das neue RequestFactory-API interessant. Dieses hat jetzt in u.a. in der Service-Annotation einen locator mit dem man auf Klassen referenzieren kann, die keine statischen Methoden enthalten. Ein schönes Beispiel für den Einsatz findet sich in der GWT Google Group (zugehöriger Thread).

Der folgende Auszug ist aus dem eben genannten Thread.

public class SpringServiceLocator implements ServiceLocator {
        @Override
        public Object getInstance(Class<?> clazz) {
                HttpServletRequest request = RequestFactoryServlet.getThreadLocalRequest();
                ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(request.getSession().ge tServletContext());
                return context.getBean(clazz);
        }
}

“I annotate my RequestContext with the GWT @Service annotation (not the
Spring one). Example below:”

@Service(locator = SpringServiceLocator.class, value =
AddressService.class)
public interface AddressRequest extends RequestContext {
        // Get address by id
        Request<AddressProxy> get(Long id);
}

“Code smell” ist ein Begriff, dem man – je länger man in der Softwareentwicklung unterwegs ist – mittlerweile kaum noch entgehen kann. Sei es nun im eigenen Projekt oder in der aktuellen Fachpresse. Für jene, denen dieser Begriff noch nicht geläufig ist, sei er wie folgt kurz erklärt:

Ein “Code smell” ist ein Symptom für tieferliegende Programm-Probleme, das sich durch unschönen bzw. verwirrenden Quellcode zeigt.

Eine konkretere Herleitung findet sich u.a. auf der entsprechenden Wikipedia-Seite. Wie die obige Erklärung bereits andeutet sind Code smells eine relativ subjektive Angelegenheit. Wann ist eine Methode zu lang, oder was sind angemessene Variablenbezeichner? Eine Antwort auf diese Fragen muss man am Ende vor allem für sich selbst finden.
Was ist jedoch zu tun, wenn man über solchen Code stolpert? Wie schreibe ich z.B. eine Methodensignatur so um, dass ich sicher sein kann, dass mein Code immer noch wie vorher funktioniert? Hierfür möchte ich 3 Bücher vorstellen, die man getrost als Leitfaden für Erkennung, Vermeidung und Aufräumaktionen verwenden kann.

Clean Code stellt viele Aspekte für unschönen Code vor, die man bei der täglichen Arbeit zwar bemerkt, aber bei denen man unter Umständen nicht immer weiss wie man sie besser machen kann. Der Autor gibt sich hierbei nicht den Anspruch des allumfassenden “So-und-nicht-anders”, sondern lässt Freiraum für eigene Entscheidungen.

Martin Fowler stellt verschiedene Refactoring-Mechanismen vor und erklärt die Motivation, die hinter jedem einzelnen steckt. Da es sich hierbei u.a. auch um sehr triviale Refactorings handelt, wirkt das Buch zeitweise etwas trocken.
Dies wird jedoch durch die Darstellung verschiedener “Bad smells in Code” teilweise wieder ausgeglichen.

Ähnlich aufgebaut wie das “Refactoring”-Buch werden hier verschiedene Code-Probleme anhand einfacher Beispiele erklärt und deren Lösung durch Patterns oder in Richtung eines Patterns vorgestellt.

Wer sich etwas konkreter mit Refactoring an sich beschäftigten will, seien diese Bücher ans Herz gelegt. Wer meint, er schreibe bereits guten Code, möge folgenden Auszug aus “Clean Code” selbst prüfen: Guten Code erkennt man an der Metrik der WTF/minute eines Code Reviewers.

Die Entwickler der RequestFactory haben sich nämlich ein schönes Konstrukt in der Klasse ReflectionBasedOperationRegistry ausgedacht, welches es nur gestattet entweder statische Methode oder eine Methode der Entity selbst aufzurufen.

boolean isInstance = InstanceRequest.class.isAssignableFrom(requestMethod.getReturnType());
if (isInstance == Modifier.isStatic(domainMethod.getModifiers())) {
  throw new IllegalArgumentException("domain method " + domainMethod
          + " and interface method " + requestMethod
          + " don't match wrt instance/static");
}

Zur allgemeinen Verteidigung: in der kommenden Version GWT 2.1.1 wurde diese Einschränkung angeblich schon ausgebaut. Da zum aktuellen Zeitpunkt allerdings nicht klar ist, wann diese Version veröffentlicht wird, muss man sich mit anderen Mitteln behelfen. Eines dieser Mittel möchte ich kurz vorstellen.

Die Idee hinter dem ganzen ist es einen Adapter zu schreiben, der die notwendigen statischen Methoden für die RequestFactory bereitstellt und diese an den eigentlichen Service delegiert.
Ich gehe davon aus, dass der Leser mit dem Grundprinzip der GWT RequestFactory vertraut ist. Falls nicht, empfehle ich einen Blick auf diese Seite.

Als Erstes möchte ich die RequestFactory vorstellen:

public interface SampleRequestFactory extends RequestFactory {

    @Service(SampleRequestAdapter.class)
    interface SampleRequestContext extends RequestContext {
        Request<List<SampleEntityProxy>> findAll();
    }

    SampleRequestContext sampleRequestContext();
}

Für diejenigen, die sich mit Spring auskennen sei darauf hingewiesen, dass die obige Service-Annotation nicht die von Spring, sondern die von GWT ist.

Weiter im Text …

Der entsprechende Adapter könnte in etwa so aussehen.

public class SampleRequestAdapter {

    private static SampleService _sampleService;

    public static void setApplicationContext(ApplicationContext applicationContext) {
        _sampleService = applicationContext.getBean(SampleService.class);
    }

    public static List<SampleEntity> findAll() {
        return _sampleService.findAll();
    }
}

Soweit, sogut. Bisher ist noch nichts Spannendes passiert. Dennoch ist die Luft bereits erfüllt mit “Entwickler-Magie”. Die offene Frage ist nämlich: Wie wird die Methode setApplicationContext() aufgerufen?

Die Lösung ist zwar nicht zwingend schön, aber wirkungsvoll:

• Man nehme eine Klasse, die von Spring verwaltet wird.
• Mache diese Klasse ApplicationContextAware.
• Gebe dieser Klasse die Adapter als Parameter und rufe für alle die Setter-Methode auf.

Im Code-Gewand sähe dies so aus:

public class ApplicationContextProvider implements ApplicationContextAware {
    private List<Class> _requestAdapters;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        if (_requestAdapters != null) {
            for (Class requestAdapter : _requestAdapters) {
                try {
                    final Method setter = requestAdapter.getDeclaredMethod("setApplicationContext", ApplicationContext.class);
                    if (Modifier.isStatic(setter.getModifiers())) {
                        setter.invoke(requestAdapter, applicationContext);
                    }
                // ... exception handling code
            }
        }
    }

    public List<Class> getRequestAdapters() {
        return _requestAdapters;
    }

    public void setRequestAdapters(List<Class> requestAdapters) {
        _requestAdapters = requestAdapters;
    }
}

Abschließend muss der Provider selbstverständlich noch für Spring verfügbar gemacht werden.

<bean class="de.sampleproject.ApplicationContextProvider">
  <property name="requestAdapters">
    <list>
      <value>de.sampleproject.SampleRequestAdapter</value>
    </list>
  </property>
</bean>

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.

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:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:py="http://genshi.edgewall.org/"
      xmlns:xi="http://www.w3.org/2001/XInclude"
      py:strip="">

  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()|text()')}
    <link rel="stylesheet" type="text/css"
          href="${href.chrome('common/style.css')}" />
  </head>

  <body py:match="body" py:attrs="select('@*')">
    <!--! Add site-specific header -->
    <div id="siteheader">
       <xi:include href="site_header.cs">
         <xi:fallback />
       </xi:include>
    </div>

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

    <!--! Add site-specific footer -->
    <div id="sitefooter">
      <xi:include href="site_footer.cs">
        <xi:fallback />
      </xi:include>
    </div>
  </body>
</html>

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:

• http://genshi.edgewall.org/
• http://www.clearsilver.net/docs/

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

<link rel="stylesheet" href="/trac/templating/chrome/common/css/trac.css" type="text/css" />

folgendes wird

<link rel="stylesheet" href="http://localhost/mytemplate/css/trac.css" type="text/css" />

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.

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
<VirtualHost *: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/
	<Directory "/var/lib/tomcat6/webapps/">
		Options Indexes FollowSymLinks +Includes
		AllowOverride All
		# DirectoryIndex index.jsp
	</Directory>
	#Mount the folders with jsp pages
	JkMount /* worker1
</VirtualHost>

<VirtualHost *:80>
	ServerName 127.0.0.3
	ServerAlias apache.localhost
	ServerAlias www.apache.localhost
	ServerAdmin webmaster@apache.localhost

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

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

	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/"
    <Directory "/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
    </Directory>
</VirtualHost>

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:

1. Aktivierung von Port 8009 und
2. 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

...
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
...

Die Server-Aliase werden im Abschnitt Host eingetragen.

...
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
  ...
  <Alias>www.tomcat.localhost</Alias>
  <Alias>tomcat.localhost</Alias>
  <Alias>127.0.0.2</Alias>
  <Alias>tomcat.localhost</Alias>
</Host>
...

/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