There are as many different approaches to this as there are implementations. In this blog I try to identify a few of the better approaches and a few of the poorer ones. The blog is not so much meant as a critique on the frameworks that the examples are taken from, but more as a guide to designing your own annotations whenever you might be faced with that task.

Prime examples: JPA annotations

The best examples of using annotations for configuration – both good and bad – can be found in JPA Entity classes.

@Entity
@Table(name="person")
public class Person {

  @Id
  @GeneratedValue(strategy=SEQUENCE)
  @Column(name = "personId")
  private Long id;

  @Valid @NotEmpty
  @OneToMany(cascade = CascadeType.ALL)
  @JoinColumn(name = "personId", nullable = false)
  @org.hibernate.annotations.Cascade(CascadeType.DELETE_ORPHAN)
  @org.hibernate.annotations.IndexColumn(name = "position")
  private List<Address> addresses = new ArrayList<Address>();
  ...
}

What a wealth of annotations! And in such a few lines of code. Anybody that has dealt with this type of code before however, will testify that this example is not overly complex at all. You’ll find this ind of code all over.

To start with, let’s say that I think this type of coding has been extremely successful. So regardless whether we find the usage of annotations in this example recommendable or not, if you work with Java code, you’ll be reading and writing a lot of code like this, so understanding it is imperative. However success is just one of the indicators for quality and it is always good to think about how things can be improved.

A perfect annotation

Of course there is no such thing as a perfect annotation. But as a general rule of thumb a good annotation should describe the annotated element and be meaningful outside its intended context. This last requirement is a little bit vague. I hope it will become more clear once we look at some examples.

Annotations are very often used as a convenient means of configuration. This type of usage breaks the above rule for ‘perfect annotations’, but they are very convenient and very widely used. Drawbacks of this type of usage are:

1. To change the configuration the source code needs to be recompiled.
2. The annotations (and thus their containing packages and often all of the framework code) need to be on the classpath for compilation and running.
3. Only one configuration can (usually) be specified. Most frameworks allow for a different means of configuration to circumvent this.

…but these drawbacks do not mean that this type of usage has been less successful in the wild. On the contrary! There are however ways to design frameworks so that they can be configured by annotations that are not impacted by these drawbacks.

Let’s look at the example above in the light of these

1. The @Entity annotation specifies that instances of this class should contains data that is to be persisted. It describes how the class is intended. It also allows several frameworks to operate on it.
2. The @Table annotation is pure configuration. It does not describe anything about this class and is tightly bound to its context: Databases.
3. The @Valid and @NotEmpty annotations describe features of valid instances of this class. They are however quite tightly bound to their context: data validation.

For each of the annotations in the example such a analysis can be made. It is interesting to think about how useful the annotations are in relation how perfect they are: The @Entity annotation, although being almost perfect is, is actually superfluous, because it will never be used without the @Table annotation. The @Valid and @NotEmpty annotations are much more useful: They allow very powerful cross-cutting concerns to be implemented with very little code, configuration or dependency of application code on framework code, making it easy to test and reuse this code.

Configuration annotation patterns in the wild

The Worst

All this dribble about perfect annotations is nice and dandy, but where does it lead us? Maybe it is better to look at the other end of the spectrum, where we find the very worst of annotations:

  @XmlJavaTypeAdapter(CurrencyAdapter.class)
  private BigDecimal price;

This JAXB annotation, used to configure the way a value is represented in XML, ties the implementation of a framework interface to the field on the domain class we’re trying to configure the framework for. We could as well implement the interface in the class itself!

Better… Level of indirection

A better pattern can be found in the seam framework for configuring interceptors. The following code configures an interceptor around a business method to measure the time it takes to complete.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Interceptors(SeamTimingInterceptor.class)
public @interface MeasureCalls {}

...
	@MeasureCalls
	public void someBusinessMethod() {
		...
	}
...

@Interceptor(around = {
	BijectionInterceptor.class,
	...
	SeamInterceptor.class,
})
public class SeamTimingInterceptor {

	@AroundInvoke
	public Object timeCall(InvocationContext invocation) throws Exception {
		long t0 = System.nanoTime();
		try {
			return invocation.proceed();
		} finally {
			long dt = System.nanoTime() - t0;
			// Log time.
		}
	}
}

The first annotation just defines a cross-cutting feature that we would like to implement in our application. We can easily use it in our application as shown by the second fragment.

Coming to the last code fragment, the actual implementation of the interceptor, i feel that the framework designers went a little overboard and were too annotation-happy: The interceptor could have simply implemented an interface:

public interface  AroundMethodInterceptor {
	Object aroundInvoke(InvocationContext invocation);
}

This would have made the contract for an interceptor much clearer.

It could also help solve the other problem with this implementation: Now, the business class needs the annotation to compile, the annotation needs the interceptor and the interceptor needs the framework classes. From this perspective, the extra level of indirection has not helped a bit.

Best… Classpath scanning and interfaces

Another approach that is quite elegant is the JAX-RS approach to extending the framework through Providers and the RESTEasy implementation for it. The code below automatically registers an exception mapper, which integrates with the framework and is used to handle EJB exceptions coming from resource methods.

@Provider
public class EJBExceptionMapper implements ExceptionMapper<EJBException> {

	@Context
	private Providers providers;

	@Override
	public Response toResponse(EJBException exception) {
		while (exception.getCause() != null
				&& exception.getCause() instanceof EJBException) {
			exception = (EJBException) exception.getCause();
		}
		Exception cause = exception.getCausedByException();
		ExceptionMapper delegate = providers.getExceptionMapper(cause.getClass());
		if (delegate != null) {
			return delegate.toResponse(cause);
		} else {
			return ExceptionUtil.serverError(cause.getMessage());
		}
	}
}

The good thing here is that the framework will scan for the annotation and then register the class according to its interface it implements.

Another interesting aspect is the @Context annotation, that basically works as an injector point.

Extensions for custom annotations

This mechanism can be used to configure the RESTEasy framework to handle custom annotations for custom serialization. Jackson has a similar mechanism like JAXB for configuring the way a field is seriaized with the @JsonSerializer annotation. Unfortunately this has the same drawbacks. A better approach can be implemented using the Provider mechanism on the Jackson framework itself.

@Provider
public class ObjectMapperResolver implements ContextResolver<ObjectMapper> {

	private AnnotationIntrospector annotationIntrospector;

	public ObjectMapper getContext(Class<?> type) {
		return new CustomObjectMapper();
	}

	class CustomObjectMapper extends ObjectMapper {

		/**
		 * Constructor.
		 */
		public CustomObjectMapper() {
			super(null, null, null,
					new SerializationConfig(
						DEFAULT_INTROSPECTOR,
						pair(annotationIntrospector,DEFAULT_ANNOTATION_INTROSPECTOR),
						STD_VISIBILITY_CHECKER, null),
					new DeserializationConfig(DEFAULT_INTROSPECTOR,
						pair(annotationIntrospector,DEFAULT_ANNOTATION_INTROSPECTOR),
						STD_VISIBILITY_CHECKER, null)
					);
		}
	}
}

The above class ‘provides’ the Jackson framework with a custom ObjectMapper. This is done automatically, because the class is annotated with @Provider and implements ContextResolver<ObjectMapper>. Now the RESTEasy framework recognizes this as a part of the framework that will provide a ObjectMapper to inject into a @Context injection point. The Jackson framework uses the same injection point to find a ObjectMapper to use for serialization.

Now how do we get it to recognize our own annotations? The answer is given by the code below, which is used in the custom ObjectMapper.

public class CustomAnnotationInspector extends NopAnnotationIntrospector {

	private Map<Class<? extends Annotation>, String> serializerComponents =
		new HashMap<Class<? extends Annotation>, String>();

	@Override
	public Object findSerializer(Annotated am, BeanProperty bp) {
		if (property != null) {
			for (Annotation annotation : bp.getMember().getAnnotated().getAnnotations()) {
				String name = serializerComponents.get(annotation.annotationType());
				if (name != null) {
					return Component.getInstance(name);
				}
			}
		}
		return super.findSerializer(am, bp);
	}
}

This can be used as shown below, when a serializer for the @Currency is configured in the seriliazerComponents map. (We use this in combination with the Seam framework for configuration).

@Target({FIELD, METHOD})
@Retention(RUNTIME)
public @interface Currency {}

...
	@Currency
	BigInteger price;
...

Conclusion

In this blog I’ve shown a number of patterns for configuring frameworks using annotations. I’ve also shown some useful classes for extending the RESTEasy and Jackson frameworks with support for custom annotations. I hope these examples will inspire you to write your own perfect and useful annotations.

1. The BLD (build) project is the parent project of all the other projects, that in turn are modules of the BLD project. The main purpose of this project is to provide a place for common configuration and a common build for all modules.
2. The WAR project depends on the EJB project, because it will use some of the services.
3. The EAR project depends on both the WAR and the EJB project, because these should be packaged in the ear.

Maven – Dependencies
Maven is all about dependencies. Luckily Seam libraries are available in the repositories, both the special repositories hosted by JBoss and the central repository. And there is more: Seam provides a very useful maven project, that can be used as the parent for our own project: org.jboss.seam:root. This project contains the JBoss repositories and a dependency management section that will ensure that compatible versions of all libraries are referenced. So the first step is to make our BLD project a child of the org.jboss.seam:root project.
Then we have to add the necessary dependencies for Seam.

• The EJB project depends on org.jboss.seam:jboss-seam:ejb and on org.hibernate:hibernate-entitymanager, since we’re gonig to use hibernate for persistence.
• The WAR project depends on org.jboss.seam:jboss-seam-ui. Now depending on your preference of front end technology, other dependencies will need to e added, but we will come to that later.

The good thing is that since we’re using the org.jboss.seam:root as parent, we don’t need to specify versions, this is handled by dependency management.
The Maven structure and dependencies (and some more support files like web.xml and ejb-jar.xml) can be packaged in a Maven archetype. Attached to this blog, you can find the one we are building right now. It can also be found in Xebias Opensource Maven repository or the snapshot repository.

Eclipse
Now, after handling Maven, let’s turn our attention to this Eclipse beast. We would like to have an easy path from the Maven project to the Eclipse development environment. Eventually we would like to have JBoss Tools running out-of-the-box starting from the simple Maven project. First let’s take a look at a JBoss Tools Seam project.
The image on the left shows the outline of a Seam project as created by JBoss Tools. There are 4 projects: test (WAR), test-ejb, test-ear and test-test. The last contains the tests, which in a maven project will be part of the same project, so we will not discuss it further. The other three projects are WTP enabled projects. looking at the configuration files (.settings/org.eclipse.wst.common.component in each project), we find that it is using WTP version 1.5.
Now we’ll try to build a similar configuration starting from the maven project.

Eclipse – WTP support
Maven has a maven-eclipse-plugin, that has as sole purpose to transform a maven project into a working eclipse project configuration. Unfortunately, it’s WTP support is seriously broken. To configure the plugin, we use this XML snipped, taken from the official documentation.

        maven-eclipse-plugin
        
          true
          true
          true
          1.5
          ${basedir}/src/main/resources/META-INF/MANIFEST.MF
        
      
    

This snipped should be placed in the pom.xml of the BLD project, so it is applied to all projects.

Now, running the eclipse:eclipse maven goal on the BLD project will generate the eclipse configuration (.project, .classpath and WTP files) for all projects. The version of the JEE specifications will be inferred by the maven-eclipse-plugin by looking at the maven dependencies for the respective specifications. To make sure the plugin generates the correct WTP configuration, we need to add the javax.ejb:ejb-api:3.0 dependency to the EJB project and the javax.serlet:servlet-api:2.5 to the WAR project. With this, the configuration for these two projects is working fine. Unfortunately, the EAR project is not working and cannot be deployed. For some reason WTP does not recognize the modules for this project and when trying to deploy it, some ClassCastException is thrown. So much for maven-eclipse-plugin…

eclipse:m2eclipse
…or not? The plugin features another goal, that could be useful here: eclipse:m2eclipse. This will generate the eclipse configuration in the same manner, but it will add the M2Eclipse plugin to the projects. This plugin has a lot of useful features: It makes synchronizing the eclipse configuration with the maven configuration a breeze. It will, for example, add the maven dependencies to the eclipse classpath, but it will also synchronize other properties, like the java version. Furthermore adding dependencies and changing the POM in general becomes really easy and, finally, creating new Maven project or modules from within eclipse becomes really easy.
This way of setting up the eclipse project is rather different from the previous one: In stead of generating all the configuration files correctly, the M2Eclipse plugin works from within eclipse to synchronize the eclipse and WTP configuration. The eclipse:m2eclipse goal does not work well with the configuration given above for the eclipse:eclipse goal, especially for EAR projects. It is better to remove all configuration from the maven-eclipse-plugin configuration and let the plugin do it’s work. This means that after generating the eclipse project files, you’ll have to open the Eclipse workspace and kick-off the synchronization process manually. More about this can be found on the Maven site for the archetype.

JBoss Tools support
JBoss tools is a Eclipse feature, that can be enabled on a project by adding some configuration (JSF and Seam facets, the SeamBuilder and SeamNature) to the eclipse project. JBoss Tools will manage two projects: the WAR and the EJB project, but the WAR project will be the main source of configuration. By adding the necessary items to the maven-eclipse-plugin configuration for this project and also adding a special Seam configuration file to the .settings directory, JBoss tools will recognize the project correctly.
For some reason, JBoss tools also stores some configuration in the workspace configuration. This can not be configured from the Maven Archetype and thus the JBoss Tools configuration is not complete. Because of this, the link between the WAR and EJB project will not be found by JBoss Tools from the EJB project. When a new Seam Artifact (Action, Entity, Form or Conversation) is added from the EJB project context meny, the configurations made in the WAR project are not picked up. When adding from the WAR project they are picked up and some sources will also be written in the EJB projects, as required.

JBoss Tools – JSF templates
JBoss Tools will generate Java sources and JSF pages when a new component is added. The JSF pages expect certain templates to exist in the Seam project and wont work correctly if they are not found. Adding these files to the Maven Archetype makes the generated JBoss Tools project work correctly. Also the Maven projects needs additional dependencies on RichFaces and Facelets in a certain configuration (some jars should go in the WEB-INF/lib, some in the EAR/lib) to make the deployed application work correctly.
The JBoss Tools project generated by the (current version of the) archetype will be exactly the same as a project created from within JBoss Tools, except for the security configuration.

Deploying on JBoss – application.xml troubles
One last problem arises when trying to deploy the generated application on JBoss AS 4.2: It will complain about the missing META-INF/application.xml. As per latest JEE spec, the application.xml is no longer mandatory, but JBoss AS 4.2 doesn’t handle this correctly. To make it work with WTP on JBoss and also with the Maven created artifacts, we have to apply a few tricks to make it all work:

1. We need to add an ‘empty’ application.xml file in the META-INF directory in src/main/application of the EAR project.
   This file is changed by the M2Eclipse plugin and used by WTP to make the deployment work on JBoss AS.
2. We let Maven generate an application.xml file during the build by setting the property generateApplicationXml on the ear plugin.
   The file is generated in the normal bulid directory and not the same as the previous.
3. We exclude the first file from the maven-bulid EAR file using the property earSourceExcludes on the ear plugin (value:META-INF/application.xml).
   this way the first file is ignored and the second is used in the maven build.

Et voila! At this point we have reached our goal of building a Seam project with Maven while still being able to use JBoss Tools, Eclipse and WTP for development.

Happy Coding!