Oli's Blog

Das Java Forum Stuttgart rückt ganz langsam näher. Bis nächste Woche hat man noch Gelegenheit, seinen Beitrag einzurichen. Mal sehen, vielleicht ist bis dahin PatternTesting 1.0 raus...

Some time ago I had problems with the jconsole on my Mac. Each time I tried to connect to a Java application the jconsole printed "Connection Failed: Retry?". This happened not at home, but outside (when I was connected via UMTS). So it seems to be a network problem.

Today I found on this Wiki entry about Monitoring Tomcat with JMX the solution for this problem. I have to add the property

-Djava.rmi.server.hostname=localhost

as parameter to the JavaVM. And voilá - I can connect now to my Java program.

Auf Marko's Software Development Blog gibt es einen sehr schönen Beitrag zu AOP und Logging. Logging wird gerne als das "Hello-World"-Beispiel für AOP abgetan (wobei hier oft "Tracing" gemeint ist) und in den meisten Fällen unterschätzt...

Gut hineingerutscht ins neue Jahr? Hoffentlich unbeschadet. Na denn, auf ein erfolgreiches Zwanzig-Zehn!

A new version of PatternTesting was released before Christmas. With this version you can now parallize your JUnit tests. You only need to put the annotation RunTestsParallel before your (JUnit 3 or 4) test class (as it is done e.g. in RunTestsParallelJUnit4Test and your test methods will be executed in parallel.

Happy Christmas...

Gegenüber Version 0.1.0, die vor ca. einem Monat ausgeliefert wurde (s. gdv.xport 0.1.0 released), hat sich einiges getan: Datensätze können auch als XML exportiert und eigene Datensätze können registriert werden. Damit ist auch der Import- und Export von Datensätzen, die noch nicht direkt von gdv.xport unterstützt werden, möglich.

Desweiteren ist inzwischen ein Hauch von Dokumentation vorhanden, um die Einarbeitung mit diesem Framework zu erleichtern. So werden die ersten Geh-Versuche anhand eines einfachen Hello-World-Beispieles erläutert.

Weitere Infos: labs.agentes.de/repository/gdv/gdv-xport/site/

Für heute hatte ich mich zum Stand-Dienst der MacIG auf der Consumer Mac Show 2009 gemeldet. Ich muss gestehen, dass ich mich nicht ganz uneigennützig dafür gemeldet hatte - ich wollte zum einen die Leute der Mac Usergroups mal persönlich kennenzulernen, zum anderen hoffte ich, den einen oder anderen Tipp mitzunehmen.

Einen dieser Tipps betrifft iMovie. In der neuen Version hatte ich es bis jetzt noch nicht geschafft, einen Video-Ausschnitt zu verlangsamen oder schneller ablaufen zu lassen. Der Trick dabei besteht darin, dass man den Ausschnitt selektiert, die Clip-Anpassungen öffnet und dann den "Tempo"-Button Gesamten Clip konvertieren selektiert. Danach hat man für diesen Clip unter Tempo wieder den Schiebregler mit Schildkröte (=langsam) und Hasen (=schnell) zur Verfügung, so wie man es aus der Vorgängerversion gewohnt war.

Das GDV-Format ist ein Austauschformat, das vom Gesamtverband der Deutschen Versicherungswirtschaft e.V. (GDV) ins Leben gerufen wurde. Leider sieht es mit Java-Unterstützung für dieses Format traurig aus - Recherchen im Sommer 2009 brachte nichts wirklich Brauchbares zu Tage.

Da wir bereits mehrere Projekte im Versicherungsbereich gestemmt haben, begann ich innerhalb unsere Firma (agentes) nachzuforschen, was an Unterstützung des GDV-Formats vorhanden war. Es war zwar nicht viel, was sich direkt verwenden ließ, aber einiges konnte dann doch in eine gemeinsame Bibliothek überführt werden - dies war der Ursprung von gdv.xport).

Mit 0.1.0 ist inzwischen die Basis gelegt, um das GDV-Format exportieren und importieren zu können. So lässt sich die GDV-Musterdatei musterdatei_041222.txt inzwischen anstandslos importieren und validieren. Was noch fehlt (neben der direkten Unterstützung der zig verschiedenen Unterformaten) ist eine aktuelle Dokumentation - das wird vermutlich mit der nächsten Version kommen.

Download: repository.agentes.de/gdv/gdv-xport/
Dokumentation: repository.agentes.de/gdv/gdv-xport/site/

Heute war der erste Tag der gearconf in Düsseldorf. Aus aktuellem Anlass hier nochmals der Link zur Einführung in FIT, die ich im Rahmen des Vortrags "Rettet die Dokumente!" vorgeführt habe.

Die Vorträge waren durchweg gut (vom Microsoft-Vortrag abgsehen, da kamen mir zuviel Abkürzungen vor), und ich konnte mir einige Anregungen für meine Projekte mitnehmen. Sehr gut war vor allem der Maven-Vortrag, aber auch der Mylyn-Vortrag konnte mich immerhin dazu animieren, es mal auszuprobieren (nicht heute, aber nächste Woche, ganz bestimmt!).

Ich bin mal gespannt, was mich morgen dann erwarten wird. Vor allem auf den Hudson-Vortrag bin ich mal gespannt, den ich gern im aktuellen Projekt einsetzen möchte (und im Moment an der Firewall hängenbleibe).

Today a new version of PatternTesting was released. Main reason of this release was the improved PatternTesting samples. You can now import it directly into your Eclipse workspace as described in "How to Run the Samples".

Happy PatternTesting...

Eher zufällig wurde ich auf die gearconf Anfang Oktober aufmerksam. Da sie in Düsseldorf stattfindet und ich dort gerade tätig bin, habe ich einen Beitrag "Rettet die Dokumente!" eingereicht, um über meine Erfahrungen mit dem FIT-Framework zu berichten (siehe dazu auch den Beitrag über Document-Driven-Development mit FIT).

Was ich mir auf der Konferenz auf jeden Fall anhören möchte, ist der Vortrag über Hudson. Zum einen, weil ich inzwischen von Continuum zu Hudson als Build-Server gewechselt bin, zum anderen, weil der Vortrag auf dem Java Forum Stuttgart als bester mit der Traumnote 1,05 bewertet wurde.

Last time we saw how we can use the ClasspathMonitor of PatternTesting and the JCconsole of the JDK to find classpath problems. But what if the program crashes immediately after you started it? You have no chance to use the JConsole here!

For this case the ClasspathMonitor can be added as shutdown hook:

---

public static void main(String[] args) throws Exception {
    ClasspathMonitor.addAsShutdownHook();
    ...
}

---

Each time your program crashes a text file "cpmonxxxxx.txt" is dumped into the temp directory. If you open this file and look for the string "IncompatibleClasses" you will see an entry like this:

...

=== IncompatibleClasses ===
class org.apache.jasper.compiler.Localizer

=== IncompatibleClasspath ===
/Users/oliver/.m2/repository/tomcat/jasper-compiler/5.5.9/jasper-compiler-5.5.9.jar
/Users/oliver/.m2/repository/tomcat/jasper-runtime/5.5.9/jasper-runtime-5.5.9.jar

...

There are two other useful side effects if you register the ClasspathMonitor as shutdown hook:

• You need not to register it as MBean (it is automatically registered).
• You'll get classes and classpathes which are never used during the lifetime of your application.

Do you know the Lava Flow Anti Pattern? PatternTesting can help you to find dead classes (and also dead methods) in your code. But this is another story...

How can classpath problems like the NoSuchMethodError described yesterday be found? The answer to this question can be found with the ClasspathMonitor provided by PatternTesting. All you need is to add patterntesting-rt-xxx.jar from PatternTesting Runtime to your classpath and to register the ClasspathMonitor as MBean:

---

public static void main(String[] args) throws Exception {
    ClasspathMonitor.registerAsMBean();
    Runner runner = new Runner();
    runner.start();
}

---

If you start the application you have to add the options

• -Dcom.sun.management.jmxremote.local.only=false
• -Dcom.sun.management.jmxremote

for JMX otherwise you would not see your application in the list of started java processes when you open JMX console.

Start your program and then the jconsole. The jconsole is since Java 5 part of the JDK. When you open the MBeans tab you can find the ClasspathMonitor MBean under the patterntesting folder. As you can guess on the screenshot below the ClasspathMonitor found an incompatible class org.apache.jasper.compiler.Localizer, i.e. this class was found more than once in the classpath (in jasper-compiler-5.5.9.jar and jasper-runtime-5.5.9.jar) but with different versions.



I don't know why I had used this version of Jasper. After I upgraded to Jasper 5.5.15 my JSP page appears without an error.

to be continued...

Jetty is a small servlet engine you can embed in your application. For my first experiment I started with a simple program to use it as HTML server:

---

public final class Runner {

    private final Server jetty;

    public Runner() {
        jetty = new Server(4040);
    }

    public void start() throws Exception {
        jetty.setHandler(new WebAppContext("src/main/webapp", "/"));
        jetty.start();
    }

    public static void main(String[] args) throws Exception {
        ClasspathMonitor.addAsShutdownHook();
        Runner runner = new Runner();
        runner.start();
    }

}

---

I have created a simple HTML page which is located in the directory src/main/webapp. After running this little Runner class from Eclipse I could see the HTML page under http://localhost:4040/.

Now I want more - I want to use it as JSP engine. Before I did a small test to use it as servlet engine which was successful (I created only a small web.xml with an InitServlet). To use Jetty as JSP environment you must include some libraries which are listed in Embedding+Jetty (e.g. the Jasper libraries).

I put the needed libraries in my classpath, created a simple JSP and started Jetty again. When I access the JSP page I got a HTTP ERROR 500 and the following stacktrace:

org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer.(Lorg/eclipse/jdt/internal/compiler/env/IBinaryType;)V

Caused by:

java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.env.NameEnvironmentAnswer.(Lorg/eclipse/jdt/internal/compiler/env/IBinaryType;)V
	at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:214)
	at org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:183)
	at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119)
	at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
	at org.eclipse.jdt.internal.compiler.lookup.Scope.getPackage(Scope.java:2149)
	...

What the hell is the problem here? My first suspicion was that it could be a classpath problem. But how can I confirm it?

to be continued...