Total Pageviews

Tuesday, December 05, 2006

JAMon to monitor performance of Java programs


I discovered a nice open source monitoring API called JAMon, which aggregates the monitoring results and performs the calculation in memory. It claims to do this in a very fast way, so you can use the tool even in production environment.

It comes with a very handy and useful web application for viewing and querying the statistics.

Combined with AspectJ anyone is able to insert performance monitoring code into an existing application without touching the existing code.

Sunday, November 26, 2006

Generic typesafe DAOs with Hibernate and Spring AOP


I am currently working on a JEE-5 project using Spring and EJB3/Hibernate. When it comes to encapsulate the access to a database the DAO pattern is used. But it has some drawbacks:

If you want to write a typesafe DAO you must repeat yourself over and over again, writing almost the same DAO code for each and every business object. Of course, you can make the DAO a generic one, but then you are loosing type safety. But there is a better way since JDK5 introduces generics.

At the W-JAX in Munich Adam Bien talked about a very good article on IBMs developer site called "Don't repeat the DAO". If you want to implement a generic and typesafe DAO using Spring and Hibernate you have to check it out at:

Another good example using plain Hibernate/EJB3 can be found on the Hibernate page under http://hibernate.org/328.html.

Sunday, November 19, 2006

Using Maven Embedder and logging almost drove me nuts


I was recently experimenting with the maven embedder component (Version 2.0.4) to embed Maven into IDEA using the embedder API.

Somehow I called the setLogger(...) method AFTER I called maven.start(). This almost drove me crazy, because I didn't get any output. The trick is, to call the setLogger(...) method before a call to maven.start(), e.g. just like this (as described in the maven docs, see http://maven.apache.org/guides/mini/guide-embedding-m2.html):


MavenEmbedder maven = new MavenEmbedder();
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
maven.setClassLoader( classLoader );
maven.setLogger( new MavenEmbedderConsoleLogger() );
maven.start();



It seems that it is currently (in Version 2.0.4) not possible to set the logger after the embedder was started.


Maybe this is helpful for others.

Tuesday, November 14, 2006

Tacx and the right contact pressure between tire and roller


Well, the summer season of cycling is over and I wanted to start practicing on my Tacx roller trainer again during the winter.

So I mounted my bike back on the trainer and started the virtual cycling. But comparing to my results of the last winter season something was totally wrong. My times were incredible slow and I had the feeling that I spent way too much power to drive as fast as the rides from last winter.

So I started digging the internet for the solution of my problem and found something interesting in a german cycling message board http://www.imagic-liga.de/n_forum/viewthread.php?boardid=4&thid=703

The pressure between the tire and the roller was incorrect! Here is what you have to do to determine the correct pressure:

  1. Start Catalyst
  2. Slope=0
  3. Accelerate to 40 km/h ~ 25 mp/h
  4. Let it roll out
  5. After approx. 10 seconds the velocity should be 0 km/h. In that case the contact pressure is correct
  6. If the tire is still rolling after 10 seconds the contact pressure is too low
  7. If the tire stops earlier the contact pressure is too high

Monday, November 13, 2006

Attended W-JAX in Munich

I attended the W-JAX in Munich from 2006-11-06 until 2006-11-09. Lots of great speakers with some very good sessions about JSF, EJB3, Application Architecture Management, Agile Development and more.

Sunday, November 12, 2006

Release of IntelliJ IDEA Maven-2 Integration plugin 1.1


This version is a feature and bugfix release. Please checkout the release notes below and also the updated documentation on http://quebbemann.kicks-ass.net/idea-maven-plugin/usage.html

Important note:

Before
version 1.1 of the plugin, Maven was called via the start script
provided with the normal Maven installation. In order to get better
access to the running Maven process Maven now is called directly by
starting a Java process. This for example allows terminating the
running Maven process by the user.

Change notes:

Bug

  • Sorting of goals should not move Phases node from top position
  • Spaces in pathname of POM file causes build failure

Improvement


New Feature
  • Add a "Cancel Build" button to the build output window
  • Add a "Close Output" button to build output window
  • Add a "Pause Output" button to build output window
  • Add a "Rerun Maven" button to build output window

Task

  • Remove references to non-public Maven repository

Thursday, November 09, 2006

Release of IntelliJ IDEA Maven-2 Integration plugin 1.0.1


Version 1.0.1 is a bugfix release:
Bug
  • Removed reference to parent POM
Improvement
  • Minor changes in build process with Maven
  • Java sources for corresponding XML schemas are generated during the build using the xmlbeans-maven-plugin
  • Updated documentation on http://quebbemann.kicks-ass.net/idea-maven-plugin
  • Added more screenshots

Wednesday, October 25, 2006

Release of IntelliJ IDEA Maven-2 Integration plugin


Today I released a Maven-2 Integration plugin for IntelliJ IDEA 5.x and 6.x. It's in a very early state but already usable. Please checkout the plugin homepage for more details and screenshots.

Friday, September 29, 2006

XMLException: Unexpected element: CDATA with XMLBeans 2.x - Read the API docs carefully


I recently got an exception while parsing a XML file with XMLBeans 2.x. During the parse of the file I received the exception:
XMLException: Unexpected element: CDATA with XMLBeans 2.x
I called the xxxDocument.Factory.parse(String xmlAsString) method with a string argument pointing to the path of the XML file to parse. Well, at that time, I expected to use the "xmlAsString" parameter as a string object pointing to the path of my XML file (should have read the API docs more carefully). That was totally wrong!
After realizing my mistake I tried the xxxDocument.Factory.parse(File file) method which I called with a File object of the XML document to parse and that did the trick!
Well, I learned my lesson: Read the API docs carefully :-)

Monday, September 25, 2006

Annotation processing with APT-Jelly


There's not much documentation about APT-Jelly out there, although the docs on the homepage are very good I decided to write a short tutorial. APT-Jelly seems to me a little bit underrated and maybe this blog entry helps it to gain more attention .

Tutorial

Given the case we want to generate local and remote interfaces for our EJB3 business class implementation. Java 5 introduces a cool tool called APT (Annotation Processing Tool) which helps the developer in generating Java source files from annotations. Unfortunately it is (just my opinion) some kind of hard work to generate those classes. You have to implement an annotation processor and walk through all of the relevant types and methods that are annotated to generate the source files. At the latest now file templates (for the Java source files) seem to be the right choice in combination with a powerful templating engine like Velocity or Freemarker.
This is the time when APT-Jelly steps in.
APT-Jelly is an engine for generating artifacts (e.g. source code,
config files) from Java source code. APT-Jelly provides a
template-oriented approach to artifact generation by providing an interface for Sun's
Annotation Processing Tool (APT) to a templating engine. Currently, APT-Jelly has direct support for both Jakarta
Commons Jelly
and Freemarker, and indirect support for Velocity
(through the merging capabilities of Jelly).
This tutorial focusses on writing Freemarker templates with APT-Jelly.
Two types of annotations are relevant for our approach: A Type annotation and a Method annotation. Let's start with writing the type annotation.
The type annotation declares, that our business class might expose its methods to either a remote or a local interface or maybe to both interfaces. It might also be helpful that the generated interface extends other interfaces. So here is the "BusinessInterface" annotation declaring the above mentioned elements:
Annotation source file: BusinessInterface.java
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.annotation.ElementType;

@Retention(value = RetentionPolicy.SOURCE)
@Target(value = ElementType.TYPE)
public @interface BusinessInterface {

String local() default ""; // FQCN of the local interface String localExtends() default ""; // FQCN of the interface the local interface should extend String remote() default ""; // FQCN of the remote interface String remoteExtends() default ""; // FQCN of the interface the remote interface should extend
}
The 2nd annotation we are going to implement is a method annotation. We would like to declare, whether the annotated method should be a member of the local or the remote interface or maybe both. So here is the "InterfaceMethod" annotation.
Annotation source file: InterfaceMethod.java
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.annotation.ElementType;

@Retention(value = RetentionPolicy.SOURCE)
@Target(value = ElementType.METHOD)
public @interface InterfaceMethod {

boolean viewTypeLocal() default true; boolean viewTypeRemote() default true;
}
Now let's create a Freemarker template in conjunction with APT-Jelly and get the whole thing running:

The template: BusinessInterface.fmt
<@forAllTypes devar="type">
<@ifHasAnnotation var="ann" annotation="BusinessInterface">
<#if (ann.remote?length > 0)>
<@javaSource name="${ann.remote}">
<#assign interfaceName = ann.remote?substring(ann.remote?last_index_of(".") + 1)>
package ${type.package};
@javax.ejb.Remote
public interface ${interfaceName} <#if (ann.remoteExtends?length > 0)>extends ${ann.remoteExtends} {

<@forAllMethods var="method" annotation="InterfaceMethod" annotationVar="annotatedMethod" returnTypeVar="returnType">
<#if (annotatedMethod.viewTypeRemote = true)>
${method.returnType} ${method.simpleName}(<@forAllParameters var="param" indexVar="paramIndex"><#if paramIndex = 0>${param.type} ${param.simpleName}<#else>, ${param.type} ${param.simpleName})<@forAllThrownTypes var="exception" indexVar="exceptionIndex"><#if exceptionIndex = 0> throws <#else>, ${exception};



}


<#if (ann.local?length > 0)>
<@javaSource name="${ann.local}">
<#assign interfaceName = ann.local?substring(ann.local?last_index_of(".") + 1)>
package ${type.package};
@javax.ejb.Local
public interface ${interfaceName} <#if (ann.localExtends?length > 0)>extends ${ann.localExtends} {

<@forAllMethods var="method" annotation="InterfaceMethod" annotationVar="annotatedMethod" returnTypeVar="returnType">
<#if (annotatedMethod.viewTypeLocal = true)>
${method.returnType} ${method.simpleName}(<@forAllParameters var="param" indexVar="paramIndex"><#if paramIndex = 0>${param.type} ${param.simpleName}<#else>, ${param.type} ${param.simpleName})<@forAllThrownTypes var="exception" indexVar="exceptionIndex"><#if exceptionIndex = 0> throws <#else>, ${exception};



}



If you are familiar with Freemarker most of the stuff should be easy to understand. The interesting stuff are the custom directives of APT-Jelly. Those directives start with a "@". The Freemarker built-in functions start with a "#".
The lines:
<@forAllTypes var="type">
<@ifHasAnnotation var="ann" annotation="BusinessInterface">

iterates through all types (classes) with a type annotation called "BusinessInterface" we have developed earlier in this tutorial.
<#if (ann.remote?length > 0)>
Now it's interesting to see, whether we have to generate local, remote or both interfaces. We start by looking up the remote element. If the element's value length is greater 0 we assume that we have the FQCN of the remote interface and we can start generating a Java source file with this name:
<@javaSource name="${ann.remote}">
I leave out the generation of the class header (interface xxx extends yyy, etc..) and go straight on to generating the methods:
<@forAllMethods var="method" annotation="InterfaceMethod" annotationVar="annotatedMethod" returnTypeVar="returnType">
We have to iterate through all methods that are annotated with the annotation "InterfaceMethod" we developed earlier. Now we have to construct the interface methods.
<#if (annotatedMethod.viewTypeRemote = true)>

${method.returnType} ${method.simpleName}(
<@forAllParameters
var="param" indexVar="paramIndex"><#if paramIndex =
0>${param.type} ${param.simpleName} <#else>, ${param.type}
${param.simpleName}
)
<@forAllThrownTypes
var="exception" indexVar="exceptionIndex"><#if exceptionIndex =
0> throws <#else>,
${exception}
;


This expression looks very confusing (especially unformatted in this blog entry), but it is pretty simple. We determine, if the annotated method's viewType is remote (referencing the "annotationVar" variable in the @forAllMethods directive) and in this case we insert all the relevant parameters with the APT-Jelly @forAllParameters directive.
The last thing to do is adding the throws clause in case the method throws an exception (@forAllThrownTypes).
The second part of the template repeats the generating stuff for the local interfaces. The solution is not perfect, but it works and shows some of the power of APT-Jelly.

The last thing to do now is execute APT and generate the sources. There are at least 4 jar archives which must be added to the classpath when calling apt:
  1. apt-jelly-core
  2. apt-jelly-freemarker
  3. freemarker
and the jar containing the annotations we have developed for generating the business interfaces (ejb3-annotations-1.0-SNAPSHOT.jar). Assuming all the jars live in the directory e:/temp and the sources of the ejb business implementation live under the directory "ejb/", we can generate the interfaces for the business implementations with the following apt call:
apt -cp e:/temp/apt-jelly-core-2.0.1.jar;e:/temp/apt-jelly-freemarker-2.0.1.jar;
e:/temp/freemarker-2.3.8.jar;e:/temp/ejb3-annotations-1.0-SNAPSHOT.jar -s target/gen -factory net.sf.jelly.apt.freemarker.FreemarkerProcessorFactory -Atemplate=BusinessInterface.fmt ejb/*.java

This will generate the business interfaces in the specified target directory (target/gen).
So let's have a look at some sample Java code using the above developed annotations. Assuming the following business class implementation:
package ejb;

import java.util.HashMap;

@BusinessInterface(remote = "ejb.InterfaceTestRemote",
remoteExtends = "ejb.InterfaceBase",
local = "ejb.InterfaceTestLocal")
public class InterfaceTestImplementation {
@InterfaceMethod
public void testDummy() throws Exception {

}

@InterfaceMethod
public String testDummy2(String dummyString) throws IllegalStateException, IllegalArgumentException {
return "";
}

@InterfaceMethod(viewTypeLocal = false)
public String testDummy3(String dummy2String, HashMap map) {
return "";
}

@InterfaceMethod(viewTypeLocal = false, viewTypeRemote = true)
public void testDummy4() {

}

@InterfaceMethod(viewTypeLocal = true, viewTypeRemote = true)
public void testDummy5() {
}

@InterfaceMethod(viewTypeLocal = false, viewTypeRemote = false)
public void testDummy6() {
}

public void testDummy7() {
}

@InterfaceMethod
public void testDummy8() {
}
}

We declare some of the methods as interface methods, some of it should appear in the remote and some of it should appear in the local interface. There are also methods which should not become a member of the generated interfaces (testDummy6 and testDummy7).
Running apt with the above mentioned command would generate the following two Java business interfaces:
InterfaceTestRemote.java
package ejb;

@Remote
public interface InterfaceTestRemote extends ejb.InterfaceBase {
void testDummy() throws java.lang.Exception;
java.lang.String testDummy2(java.lang.String dummyString) throws java.lang.IllegalStateException, java.lang.IllegalArgumentException;
java.lang.String testDummy3(java.lang.String dummy2String, java.util.HashMap map);
void testDummy4();
void testDummy5();
void testDummy8();
}

InterfaceTestLocal.java
package ejb;

@Local
public interface InterfaceTestLocal {
void testDummy() throws java.lang.Exception;
java.lang.String testDummy2(java.lang.String dummyString) throws java.lang.IllegalStateException, java.lang.IllegalArgumentException;
void testDummy5();
void testDummy8();
}

The generated remote interface extends an already existing base interface called ejb.InterfaceBase. In a next trail I will explain how to generate those base interface as well (as proposed in the book "Enterprise Java Beans") and how to use macros (some sort of methods) in a Freemarker template.
APT-Jelly really seems to simplify a lot!