Oli's Blog

Auch wenn gdv.xport in erster Linie eine Bibliothek für den Umgang mit GDV-Datensätzen ist, lässt sich gdv-xport 0.9.3 jetzt auch direkt als Jar-Datei aufrufen, um die darin enthaltene Main-Klasse zu starten. Auch wurde für die Satzart 220 einige weitere Sparten spendiert (Sparte 110 und 140) und einige kleinere Fehler bereinigt. Ein Fehler, der jetzt bereinigt wurde, verhinderte den Import mehrerer Datenpaket mit demselben InputStream:

List datenpakete = new ArrayList();
while (true) {
    Datenpaket paket = new Datenpaket();
    try {
        paket.importFrom(inputStream);
        datenpakete.add(paket);
    } catch (EOFException ex) {
        log.info("EOF nach " + datenpakete.size() + " Datenpaketen erreicht.");
        break;
    }
}

Dies führt jetzt mit 0.9.3 nicht mehr zum Abbruch nach dem ersten Datenpaket (s.a. Release Notes).

In gdv.xport 0.9.0 hatten sich einige kleine Ungereimtheiten in einigen Feldern der verschiedenen Wagnis-Definitionen eingeschlichen. Diese sind jetzt mit 0.9.1 behoben (s.a. Release Notes).

Dank tatkräftiger Unterstützung durch Ralf Klemmer und André Janus unterstützt die gdv.xport-Bibliothek jetzt auch das Release 01.11.2009 des GDV-Handbuchs. Intern hat sich nicht viel geändert - es wurden einige Dinge bereinigt, sowie einige veraltete Klassen entfernt. Die SatzFactory hat einige register-Methoden für die Unterstützung der Wagnisart erhalten.

Inzwischen sollte 0.9.0 auch im Maven-Repository angekommen sein. Was dann mit 0.9.1 oder 1.0.0 kommen wird, kann man im Wiki unter Planungen nachschlagen.

The maven-ooo-plugin is now nearly working. mvn package generates now an OpenOffice plugin with .oxt suffix. But not always. It is hard to find the reason why the registration of the plugin can fail.

As I learned today one reason for an com.sun.star.deployment.DeploymentException can be:

• an incomplete classpath entry in the generated manifest file,
• a missing __writeRegistryServiceInfo or
• a missing __getComponentFactory method in a Java component

Unfortunately you get not really a hint form OpenOffice if the registration of a plugin fails. For more info you can read the OpenOffice forum.

Letzte Woche hatte ich mir mal kurz Spring Roo (www.springsource.org/roo) angeschaut. Erster Eindruck:

• scheint so 'ne Art "Ruby on Rails for Java" zu sein
• ist eine Sammlung von "Best Practices" bzw. "Best Tools"
• Abhängigkeiten werden über Maven verwaltet

Spring Roo kommt zwar nur als 4MB große Zip-Datei daher, aber bereits beim Generieren des ersten Projekts werden jede Menge von Bibliotheken und Plugins runtergeladen (Maven lässt grüßen!). Dafür hat man dann eine voll funktionsfähige Web-Anwendung mit JUnit- und sogar (!) Selenium-Tests, das man als fertiges Projekt in Eclipse bzw. die Springsource Toolsuite (= Spring-IDE auf Basis von Eclipse) importieren kann.

Der ersten Begeisterung folgt aber schnell die erste Ernüchterung: sobald man anfängt, den generierten Code erweitern zu wollen, wird man sehr schnell mit den darunterliegende Techniken wie Spring, JPA oder Hibernate konfrontiert. So wurde ich beim Experimentieren mit der generierten Test-Klasse gleich mit Hibernates berühmt-berüchtigter LazyInitializationException konfrontiert, weil ich die Test-Methode nicht als @Transactional gekennzeichnet hatte. Auch bei Erweiterungen an den JSP-Seiten ist man ohne SpringMVC-Kenntnisse aufgeschmissen. Dies Spring Roo anzukreiden wäre aber unfair.

Fazit: Spring Roo ist aus meiner Sicht ein Framework, das in der Java-Welt schon lange überfällig war (auch wenn mit AppFuse ein ähnlicher Ansatz bereits existiert). Es hilf einem, in kurzer Zeit einen Prototypen aufzubauen und weiterzuentwickeln. Es entbindet einen allerdings nicht von der Notwendigkeit, über die verwendeten Technologien Bescheid zu wissen.

Im ersten Teil hatten wir eine einfache Tabelle mit Rechnername und Portnummer, die wir mit Hilfe des FIT-Frameworks automatisch überprüft haben. Jetzt wollen wir alle aktiven Ports testen:

de.aosd.PortScannerFixture
Rechner	Portnummer	Status()
localhost	22	aktiv
localhost	80	aktiv

Für solche Aufgaben, wo evtl. Tabellen-Zeilen hinzukommen können, bietet sich die RowFixture an:

---

public class PortScannerRowFixture extends RowFixture {

    @Override
    public Class<?> getTargetClass() {
        return PortTester.class;
    }

    @Override
    public Object[] query() throws Exception {
        return new Object[0];
    }

}

---

getTargetClass() liefert eine Klasse zurück, die eine Reihe in der Port-Tabelle vom letzten Mal repräsentiert, und die query()-Methode liefert alle Ergebnisse zurück. Fangen wir mit getTargetClass() an und definieren dafür die PortTester-Klasse:

---

public class PortTester {
    public String Rechner;
    public int Portnummer;
	
    public String Status() throws UnknownHostException {
        return PortScanner.isActive(Rechner, Portnummer) ? "aktiv" : "inaktiv";
    }
}

---

Für die Klasse gelten die gleichen Regeln wie für die PortScannerFixture-Klasse vom letzten Mal: Überschriften werden zu Attribute bzw. zu Methoden, wenn sie mit "()" enden. Damit können wir jetzt schonmal den FileRunner aufrufen:

de.aosd.PortScannerRowFixture
Rechner	Portnummer	Status()
localhost missing	22	aktiv
localhost missing	80	aktiv

FIT bemängelt hier, das beim Test die beiden Zeilen mit Port 22 und 80 fehlen – dies liegt daran, dass query() noch ein leeres Array zurückliefert. Das wollen wir ändern und für jeden offenen Port ein PortTester-Objekt in einem Array sammeln:

---

public Object[] query() throws Exception {
    ArrayList active = new ArrayList();
    for (int i = 0; i < 1023; i++) {
        PortTester tester = new PortTester();
        tester.Portnummer = i;
        tester.Rechner = "localhost";
        if (tester.Status().equals("aktiv")) {
            active.add(tester);
        }
    }
    return active.toArray();
}

---

Hier werden jeweils für die wellknown Ports zwischen 0 und 1023 ein PortTester-Objekt angelegt. Nur wenn der Aufruf von Status() "aktiv" ist, wird es in die Liste aufgenommen und am Ende als Array zurückgegeben. Das Ergebnis auf meinem Rechner sah danach so aus:

de.aosd.PortScannerRowFixture
Rechner	Portnummer	Status()
localhost	22	aktiv
localhost	80	aktiv
localhost surplus	111	aktiv
localhost surplus	631	aktiv

Mit "surplus" werden die Spalten markiert, die hinzugekommen sind. Offensichtlich sind auf meinem Rechner noch die Ports 111 und 631 offen. Ein Blick in List of TCP and UDP port numbers offenbart, dass sich dahinter das "sun protocol" (RPC-Aufruf) und das "Internet Printing Protocol (IPP)" verbirgt.

Damit ist der kleine Ausflug in FIT beendet. Wenn Sie Interesse daran gefunden haben, dann besuchen Sie mich doch auf meinem Vortrag "Wie man tote Dokumente zum Leben erweckt" auf dem Java Forum Stuttgart.

Viel Spaß mit FIT!

Links:

• Beispiel-Projekt: portscanner080419 (zip, 7 KB)
• FIT: fit.c2.com
• Fitnesse: www.fitnesse.org

(eine kleine Einführung in das FIT-Framework)

Schon mal TDD (Test-Driven-Development) ausprobiert? Dann wird Ihnen auch sicherlich das FIT-Framework von Ward Cunningham gefallen, dass sich sehr gut mit dem TDD-Ansatz kombinieren lässt.

Basis von FIT sind Tabellen, die als Eingabe für automatische Testfälle dienen. Als Beispiel werden wir eine Tabelle mit Ports heranziehen, die wir etwas abändern werden, um unseren eigenen Rechner damit überprüfen zu können:

de.aosd.PortScannerFixture
Rechner	Portnummer	Dienst	Beschreibung	Status()
localhost	20	FTP-Data	Dateitransfer (Datentransfer vom Server zum Client)	inaktiv
localhost	22	SSH	Secure Shell	aktiv
localhost	80	HTTP	Webserver	aktiv

Die Tabelle aus Wikipedia wurde um die Spalte "Rechner" und "Status()" ergänzt. Am Anfang der Tabelle wurde noch eine Zeile mit einem sogenannten "Fixture" eingefügt. Dabei handelt es sich um eine Java-Klasse, die später vom FIT-Framework aufgerufen wird:

---

public class PortScannerFixture extends ColumnFixture {
	
    public String Rechner;
    public int Portnummer;
    public String Dienst;
    public String Beschreibung;
	
    public String Status() {
        return "not implemented";
    }

}

---

ColumnFixture ist eine Oberklasse von FIT, die den meisten Komfort im Umgang mit Tabellen bietet. Zwei Dinge sind wichtig für die Imlementierung:

1. ich muss Attribute als "public" bereitstellen, die genauso wie die Tabellen-Überschriften heißen (Rechner, Portnummer, Dienst, Beschreibung);
2. Tabellen-Überschriften, die wie Methoden-Aussehen (hier: Status()) müssen implementiert werden und einen String zurückliefern.

Damit ist das FIT-Framework bereits einsatzbereit. Über den mitgelieferten FileRunner kann das HTML-Dokument mit dieser Tabelle als Eingabeparameter aufgerufen werden:

> java fit.FileRunner services.html result.html
0 right, 3 wrong, 0 ignored, 0 exceptions

Der zweite Parameter (result.html) gibt die Ausgabedatei an, in der das Ergebnis abgelegt wird. Das Ergebnis entspricht im Wesentlichen der Eingabedatei mit Ausnahme der Tabellen:

de.aosd.PortScannerFixture
Rechner	Portnummer	Dienst	Beschreibung	Status()
localhost	20	FTP-Data	Dateitransfer (Datentransfer vom Server zum Client)	inaktiv expected not implemented actual
localhost	22	SSH	Secure Shell	aktiv expected not implemented actual
localhost	80	HTTP	Webserver	aktiv expected not implemented actual

Ok, jetzt können wir uns der Implementierung der Status()-Methode widmen, um die roten Tabellen-Einträge wegzubekommen:

---

public String Status() throws UnknownHostException {
    return PortScanner.isActive(Rechner, Portnummer) ? "aktiv" : "inaktiv";
}

---

Unter der Annahme, dass die PortScanner.isActive()-Methode das Gewünschte leistet, sollten die roten Einträge nun grün werden:

de.aosd.PortScannerFixture
Rechner	Portnummer	Dienst	Beschreibung	Status()
localhost	20	FTP-Data	Dateitransfer (Datentransfer vom Server zum Client)	inaktiv
localhost	22	SSH	Secure Shell	aktiv
localhost	80	HTTP	Webserver	aktiv

Damit wissen wir nicht nur, dass Port 22 und 80 auf unserem Rechner aktiv sind, sondern haben auch die isActive()-Methode unserer PortScanner-Klasse getestet.

Sollen noch andere Rechner oder Ports getestet werden, wird die Tabelle entsprechend erweitert. Was aber, wenn wir eine Liste aller aktiven Ports vorgeben wollen? Für solch eine Überprüfung bietet sich die RowFixture an – aber das ist ein Thema für's nächste Mal.

stay tuned...

Links:

• Beispiel-Projekt: portscanner080413 (zip, 5 KB)
• FIT: fit.c2.com
• Fitnesse: www.fitnesse.org

Dokumentation ist nicht Teil der Lösung, sondern Teil des Problems. (Tom DeMarco, Timothy Lister)

Dokumente sind oft die erste Anlaufstelle, um sich in fremde Systeme einzuarbeiten. Leider sieht es in der Praxis aber oft so aus, dass Dokumente widerwillig erstellt, nur oberflächlich geprüft und danach nie wieder angefasst werden. Entsprechend nehmen die Qualität und die Übereinstimmung mit der Realität immer mehr ab.

Mit dem FIT-Framework von Ward Cunningham besteht die Möglichkeit, Dokumente als Eingabe für Integrations-Tests heranzuziehen und damit auch die Dokumentation aufzuwerten und abzugleichen.

Auf dem iX CeBIT Forum 2008 bietet sich am 4. März ab 16:00 die Gelegenheit, Näheres über FIT zu erfahren oder/und sich auszutauschen.

It's CeBIT time!

Wer für den täglichen Build Maven einsetzt, kann zu MyFaces greifen, wenn er mit Java Server Faces (JSF) arbeiten will. Diese Bibliothek befindet sich unter ibiblio.org und lässt sich damit problemlos in das pom.xml einbinden.

Allerdings hat MyFaces 1.2.0 noch einige kleine Macken (z.B. bei der <h:dataTable>, so dass man vielleicht auf die Referenz-Implementierung (RI) der Java Server Faces von Sun zurückgreifen möchte. Aber wo bekomme ich diese Bibliothek für Maven her?

Die Lösung: für java.net gibt es ein eigenes Repository, das man unter dem Abschnitt <repositories> in sein pom.xml aufnehmen kann:

<repositories>
  <repository>
    <id>java.net</id>
    <url>http://download.java.net/maven/1</url>
    <layout>legacy</layout>
  </repository>
</repositories>

Damit kann man die Artifact-Ids jsf-api und jsf-impl unter der Group-Id javax.faces in sein pom.xml mit aufnehmen.

I started a proof of concept if Lucence could be used for searching in log files. Here a first result of the indexer (see also benchmarks of the Lucene site):

Hardware Environment


• Dedicated machine for indexing: yes
• CPU: Intel Pentium M, 1.6 GHz, 1 processor
• RAM: 2 GB
• Drive configuration: IDE 2,5" hard disk (in a Dell Lititude D810 notebook)

Software environment


• Lucene Version: 2.2.0
• Java Version: Java SE 1.6.0_02
• Java VM: client VM
• OS Version: WinXP with SP1
• Location of index: local

Lucene indexing variables


• Number of source documents: 9
• Total filesize of source documents: 15 MB
• Average filesize of source documents:2 MB
• Source documents storage location: Filesystem
• File type of source documents: log files
• Parser(s) used, if any:
• Analyzer(s) used: StandardAnalyzer
• Number of fields per document: 3
• Type of fields: text
• Index persistence: FSDirectory
• Index size: 3 MB

Figures


• Time taken (in ms/s as an average of at least 3 indexing
  runs): 7 s (first try: 37 s -> ignored)
• Time taken / 1000 docs indexed: 150 s (estimated)
• Memory consumption: started with -Xmx128m -Xms128m
• Query speed: not yet measured

Notes


• Note: first prototype, no special tuning/strategies
• Note: maxFieldLength set to 1,000,000 (default of 10,000 was to small)