Oli's Blog

Since 0.9.9 end of last year it was quite calm about PatternTesting. But now PatternTesting 1.0.0 is released.

What's new with 1.0.0? For Maven user the group id has changed to "org.patterntesting". While it is not yet sync'd to Maven's default repository you can find it in labs.agentes.de/repository/.

For Non-Maven user the download was now simplified. You need only to download patterntesting-libs-1.0.0-bin.zip from Sourceforge which contains all PatternTesting libraries and the libraries where PatternTesting depends on.

Some of the samples are now documented in the PatternTesting Wiki under Getting Started but are not yet available for download. This will come with PatternTesting 1.0.1. But you can find the sources in CVS below the patterntesting-samples module (the intro and jfs2010 directory).

With PatternTesting 1.0.0 also the home page has moved to patterntesting.org. If you are interested in PatternTesting you can see it also at the Java Forum Stuttgart at 1st July.

Happy PatternTesting...

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...

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...

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...

The old article Hello World with PatternTesting is a little bit outdated because the patterntesting-check.jar was splitted into patterntesting-check-ct.jar and patterntesting-check-rt.jar. The reason for this split was performance problems with Eclipse 3.3 (not 3.4, see also Performance Boost with Eclise 3.4 / AJDT 1.6.3). But since this week there is now a MediaWiki with a Getting Started section available.
Happy PatternTesting...

Am Donnerstag ist es soweit - da beginnen die Stuttgarter Test-Tage. Auf der Postersession am Donnerstag abend wird es dann die Gelegenheit geben, seine ersten Schritte mit PatternTesting auszuprobieren.
Resourcen:

• Einstieg in PatternTesting: patterntestingeinstieg (pdf, 504 KB)
• Beispiel-Anwendung: jugsbasepattng (zip, 2,432 KB) (inkl. PatternTesting-Bibliothek)

Happy (Pattern-)Testing!

In one of our projects we are still working with Eclipse 3.3 because we use the WTP 2.0 plugin and have failed in the past with the upgrade to Eclipse 3.4 / WTP 3.0 (we had strange classpath problems with JSF). We used one AspectJ lib (patterntesting-rt) and wanted to add also patterntesting-check as AspectJ lib. But the compile time was a desaster - it slows down to 30 seconds for an incremental build.

From the aspectj-users mailing list I got the tip to use Eclipse 3.4 with the actual AJDT plugin. And really, with this version we get a dramatic speedup for the incremental build:

	full build	incremental build
Eclipse 3.3	75 s	34 s
Eclipse 3.4	30 s	1 s

These are the time for the AJBuilder.build() we found out with the AJDT Event Trace (you can open it as view in Eclipse). As you can see the incremental compile is more than 30 times faster as before.

Nachdem ich das letztes Mal beschrieben habe, wie man die Beispiel-Anwendung zu den Test-Tagen 2009 zum Laufen bringt, möchte ich in das dort erstellte Projekt die PatternTesting-Bibliothek einbinden (Sie können es aber auch mit jedem anderen Projekt ausprobieren). Dazu brauchen wir patterntesting-rt-0.9.0.jar und patterntesting-check-0.9.0.jar, das über die PatternTesting-Homepage oder von ibiblio.org/maven2 heruntergeladen werden kann.

Da PatternTesting eine AspectJ-Bibliothek ist, müssen wir erst einmal das AJDT-Plugin installieren (s. Download-Seite des AJDT-Plugins). Danach sollte im Kontext-Menü "AspectJ-Tools > Convert to AspectJ Project" auftauchen. Dadurch ändert sich das Projekt-Icon und bekommt "AJ" als Beschriftung verpasst, wo vorher nur ein "J" stand. Ansonsten passiert nicht viel. Über den gleichen Menüpunkt "AspectJ Tools" können Sie das Projekt auch wieder zu einem normalen Java-Projekt degradieren ("Remove AspectJ Capability").

Der nächste Schritt besteht in der Einbindung der beiten Pattern-Testing-Bibliotheken. Dazu rufen wir die Projekt-Eigenschaften auf und tragen unter "AspectJ Build > Aspect Path" die beiden Pattern-Testing-Bibliotheken ein. Jetzt noch "Ok" gedrückt - das war's auch schon. Die "advice defined"-Warnungen können Sie ignorieren oder über "Project Properties > AspectJ Compiler" unter der Überschrift "Potential matching problems" abschalten, indem Sie dort "Advice did not match (Java 5 only)" auf "Ignore" stellen.

Den Warnungen "No logging should be done using the default output and error streams." sollten Sie allerdings nachgehen. Sie werden feststellen, dass hier System.out.println für die Ausgabe verwendet wurde. So etwas macht man besser mit Log4J oder anderen Logging-Frameworks.

Was man sonst noch alles mit der PatternTesting-Bibliothek anstellen, wird noch folgen...