Java

Configuration

Eine elegante Möglichkeit flexibel verschiedene Konfigurationsvarianten zu kombinieren ist das Commons Configuration Framework. Es ermöglicht Configs aus Propertie-Files, DBs, JNDI, XMLs, ... zu kombinieren.

Eine Integration in Maven braucht:
<dependencies>
    <dependency>
        <groupId>commons-configuration</groupId>
        <artifactId>commons-configuration</artifactId>
        <version>1.10</version>
    </dependency>
</dependencies>

Dabei lassen sich verschiedene Config-Quellen auch in eine gemeinsame Struktur kombinieren, der man die Herkunft nicht mehr ansieht.
Ausserdem lassen sich Teilbäume ausgeben:

CompositeConfiguration cc = new CompositeConfiguration();
cc.addConfiguration(new SystemConfiguration()); // first
cc.addConfiguration(new PropertiesConfiguration("config2.properties")); // second
cc.addConfiguration(new PropertiesConfiguration("config1.properties")); // last
Iterator<String> keys = cc.getKeys("java.vm");
while(keys.hasNext()){
    String k = keys.next();
    System.out.println(k+" = "+cc.getProperty(k));
}

Share

JBoss 7 - Was ist neu?

JBoss ist ein sehr weit verbreiteter Application Server, der eigentlich nicht explizit vorgestellt werden muss. Fast jeder hatte irgendwann mal was damit zu tun. (Streng genommen ist JBoss kein Application Server, sondern Name einer Produktfamilie. Genauso wie WebSphere eigentlich kein spezifisches Produkt bezeichnet. Ich werde mir die Struktur der Produktfamilie in einem anderen Blog vornehmen)

Grundsätzlich gibt es die frei verfügbare Version von JBoss und die kostenpflichtige Fassung rund um JBoss EAP (Enterprise Application Plattform). Die freie Version ist EAP quasi immer einen technologischen Schritt voraus. Ein Blick auf JBoss AS 7 zeigt also was in EAP 6 kommen könnte. Da JBoss beim Wechsel auf Version 7 keinen evolutionären sondern einen revolutionären Schritt gemacht hat, möchte ich die wichtigsten Unterschiede hier zusammenfassen.

Es fängt damit an, dass AS7 praktisch komplett neu entwickelt wurde. Die etablierten Bausteine (z.B. Microcontainer) wurden ersetzt und durch eine grundsätzlich andere Architektur ersetzt. Zentraler Unterschied der neuen Architektur ist der modulare Aufbau, dank dem Komponenten erst bei Bedarf gestartet werden. In Profilen kann definiert werden, welche Komponenten anfänglich gestartet werden.

Das Modulsystem nennt sich JBoss Modules und ist ein eigenständiges Projekt, welches auch für andere Projekte eingesetzt werden kann (es geht in die Richtung der für Java 7 versprochenen Modullösung (JSR 294), welche nun bis Ende 2012 als Teil von Java 8 verschoben wurde). Unter Modul wird eine Komponente verstanden, die mit eigenen Ressourcen und Klassen daher kommt und Abhängigkeiten zu anderen Modulen hat. Diese Abhängigkeiten definieren, welche Funktionalitäten von Modul B Modul A sehen kann. Dies entspricht quasi einem 5. Visibility Level in Java, also einer Steigerung von 'public'. Dieser Ansatz löst massenweise Probleme: die Startup-Zeit und der memory footprint wurden massiv verringert. Viel wichtiger ist, dass Module jeweils mit eigenem ClassLoader kommen und die mühseligen ClassPath-Problematiken der Vergangenheit angehören.

JBoss 7 unterstützt Hibernate, Weld, Mojarra und viele weitere opensource Standards. JBoss 7 bietet JavaEE6 Support (Web-Profile; Full Profile folgt in 7.1 später dieses Jahr).

Eine weitere, gut sichtbare Änderung ist das neue GWT-basierte Admin-GUI. Es lässt sich darüber streiten, ob ein solches GUI notwendig war; aber besser aussehen tut's auf jeden Fall ;-)

Neu unterstützt JBoss AS 7 zwei Betriebsmodi: standalone und domain. Stand-alone entspricht ungefähr der bisherigen Betriebsweise. Dabei laufen alle Komponenten (Host Controller und einer oder mehrere managed Application Server auf derselben Maschine). Ein Deployment besteht aus dem Kopieren des WAR-Files nach /standalone/deployments. Dieses Verzeichnis wird vom Deployment Scanner überwacht. Via Filename-Anpassungen wird über den (Miss-)Erfolg von Deployments informiert (neue File-Endung '.deployed' oder '.failed'). Domain unterstützt die Verwaltung mehrerer gemanagte Server (auch auf unterschiedlichen Maschinen). Neben HC und AS kommt bei Domain auch noch ein Domain Controller zum Einsatz, der die einzelnen HCs überwacht. Die einzelnen Application Server werden üblicherweise in Servergruppen zusammengefasst, die betriebliche Funktionen haben (z.B. Test, Integration, Produktion). Diese Servergruppen können mehrere physikalische Server belegen. Applikationen werden in eine Domain geladen und können dann in den verschiedenen Umgebungen deployed werden (Achtung: Konfigurationsdetails wie DB, Log-Settings, ...). Ein Deployment via File copy ist nicht mehr möglich.

Eine weitere spannende Möglichkeit ist die Integration von JBoss in Unit und Integration Tests. Während in vielen Fällen Unit-Tests gar keinen laufenden Application Server mehr benötigen (Stichwort: POJO), gibt es doch noch einige Fälle in denen ein solcher notwendig wäre. Häufig scheitert es daran, dass "professionelle" Application Server nicht sinnvoll in Tests integriert werden können, da sie zu lange zum Starten brauchen, man nicht die entsprechenden Einstellungen mitgeben kann oder eine Integration in einen Testlauf einfach nicht machbar ist. Natürlich gibt es die Möglichkeiten Jetty für gewisse Tests einzubinden, aber der verhält sich wahrscheinlich leicht anders als das System, welches produktiv zum Einsatz kommt. Kurz: man will auf dem Server testen, welcher am Ende des Tages produktiv zum Einsatz kommen wird.

Last but not least, gibt es in JBoss 7 eine Kommandozeile (bin/jboss-admin.sh) für die Administration ohne WebGUI. Mittels Batch-Blöcken lassen sich mehrere Änderungen in einer Transaktion ausführen, um den Server nicht 'unterwegs' in inkonsistente Zustände zu bringen.

Kommentare in Java-Klassen

Kommentare haben fast so einen schlechten Ruf wie Testklassen, dabei sind sie fast genauso wichtig wie diese. Schliesslich helfen beide dabei, wartbare Applikationen zu schreiben. Je nachdem ist man selbst der direkt Betroffene, wenn man in ein paar Monaten an dieser Applikation eine Anpassung machen muss und nicht mehr weiss, um welchen Spezialfall es sich hier genau handelt. Deshalb lohnt es sich hier ein bisschen Zeit zu investieren. Ich möchte kurz meine Erfahrungen zum Thema 'Sourcecode kommentieren' beschreiben.

Nie den Sourcecode 1:1 kommentieren

Es bringt nichts im Kommentar zu schreiben, was bereits programmiert wurde. Wieso sollte jemand folgendes lesen wollen?

//füge Adresse in Adressliste ein
adresslist.add(adress);

Das hilft niemandem weiter. Kommentare müssen einen Mehrwert liefern. Also macht es zum Beispiel Sinn vor einem komplexen Algorithmus dessen Namen in den Kommentar zu schreiben.

Bei Business-Funktionen ist es sinnvoll Referenzen in die Spezifikation oder ins Issue Management System in die Kommentare zu schreiben. Wenn aus der Spez oder dem Issue dieses Implementierungsdetail nicht hervorgeht und es sich um einen genügend komplexen Codeblock handelt, sollte hier direkt ein Kommentar stehen, was man hier programmiert.

Sprache der Kommentare

Wenn das Team deutsch spricht, alle Dokumente deutsch sind und der Sourcecode intern bleibt, dann ist es irr englisch zu kommentieren.

JavaDoc in Schnittstellen

Schnittstellen beinhalten Methoden, die von anderen Teilen der Applikation aufgerufen werden. Hier ist eine Dokumentation besonders wichtig, da IDE's die Beschreibungen bei der Arbeit mit diesen Schnittstellen darstellen.

Keine Namen

Es bringt nichts in Kommentaren den eigenen Namen hineinzuschreiben. Diese Information kommt aus dem Sourcecode Verwaltungssystem (SVN, CVS, ...).

Review

Wie "normaler" Code sollten auch Kommentare reviewt werden. Was nützt ein Kommentar den niemand sonst versteht?

Share