Luckily, the Maven Release plugin can help you automate the whole process of upgrading your POM version number and tagging a release version in your version control system, and all of this with a single maven command. You can even automate the entire release process by running the command in a cronjob or a Continuous Integration system. Amazing!

Here is an extract from a project’s top POM file, showing the version number that uniquely identifies this version.

The SNAPSHOT suffix means that each time I deploy this version, a new snapshot will be deployed into my local Maven repository. Anyone who wants to use the latest, bleeding-edge SNAPSHOT version can add a SNAPSHOT dependency in their project. Snapshots, by definition, tend to be fairly unstable beasts.

When the version 1.1 is ready, you need to:

1. update the POM file
2. commit the new POM file to version control
3. tag this version as a release
4. and then move on to work on version 1.2

The Maven Release plugin can automate much of this process. However, before the Maven Release plugin can do its work, you need to make sure you have everything it needs set up in your POM file.

First of all, you need to be working with a SNAPSHOT release. However, when you are ready to release your new version, you should remove any references to snapshots in your dependencies. This is because a release needs to be stable, and a build using snapshots is, by definition, not always reproducible. Maven will not accept any snapshot references and force the user to change it during the release process. If you answer is no (as below) to the question of resolving dependencies or not, Maven will fail your build.

The next thing you need is another section in your POM file. Maven will tag your project and commit it to your source control system. So it needs to know the location of your source control system. You generally don’t need to specify credentials as Maven inherits those from the environment. If Maven needs credentials it will prompt you during the release process.

You can find reference documentation for the <scm> tag here.

Next, you need to configure the Release plugin itself. This mainly involves telling Maven where your release tags go, via the "tagBase" configuration element. If you are using the Subversion trunk/tags/branches convention, Maven will automatically put release tags in the "tags" directory. I prefer to use a a slight variation on the normal convention, and place releases in the "tags/releases" directory:

Now it's time to get down to business, and try out a (semi-)automated release. The first thing you need to do is to make sure all your latest changes have been committed to your SCM system. If there are any outstanding changes, Maven won't let you do a release. First of all, you need to prepare the release, using the "prepare" goal:

This goal will ask you a series of questions to confirm:

• what version number you want to release
• what new snapshot version number you want to use
• where you want to place the release tag.

If you have set up your POM file correctly, these will have sensible defaults, and you won't have to do much thinking. If you which you can disable these questions using the "--batch-mode" command line option. But to me it's a good last healthy check walking through these questions.

If you want to know exactly what Maven will do to your POM file and your SCM ahead of time (generally a good idea), you can run the operation in the "dry-run" mode, as shown here.

This useful trick simulates the SCM operations by writing them out to the console, and creates three sample POM files that you can consult:

• pom.xml.tag, which is the pom file that will be committed to Subversion and tagged
• pom.xml.next, which contains the next snapshot version number

I recommend you to do a dry-run the first time you're doing you use the Maven Release plugin. It is very useful and will learn you about the set up of your own project and sub-projects. When you're satisfied with what Maven will do, you can do it for real:

Things you should know about the prepare goal:

1. The command checks for local modifications. If you have any modified files but not checked in, the command will stop and ask you to first check-in modified files.
2. Your project cannot have any SNAPSHOT dependencies in your project. It's a requirement.
3. You will be asked to specify versions for the release and the next SNAPSHOT (e.g. going from "1.1-SNAPSHOT" to "1.1"). Accept the default values if unsure.
4. Maven will run all your unit tests to make sure they work after changing the project version in pom.xml.
5. Commit the changes made to the POM file
6. If all tests pass, Maven will tag the source in the source control with the release version you specified in step 3 above.
7. Update the SNAPSHOT version number to a new SNAPSHOT version (e.g. going from "1.1" to "1.2-SNAPSHOT")
8. Maven collects all the information that you provide and write a local file called release.properties. This file lets you continue from where you left in case of errors.
9. Undo. You can undo everything you’ve done so far with mvn release:clean to start all over.

Indeed, the prepare goal does quite a lot. Once you're finished, you have your release version tagged in Subversion and you are working on a new SNAPSHOT version.

So far we have only set everything up in preparation for the release. Nothing have actually been released yet. But dont worry, performing the release is easy. Just use "mvn release:perform" command:

This will effectively do a mvn deploy with the release we have just created. More precisely, it will use the release.properties file generated by the release:prepare goal to do the following:

• Check out the release we just tagged
• Build the application (compiling, testing and packaging)
• Deploy the release version to local and remote repositories

However, both of these steps can be made into a single line command and placed, for example, on a Hudson server.

Single line release process

This single line command will tag source control, bump up the current pom.xml, version and push a tagged artifact (jar or war) to a remote repo.

For example, if your current project version was 1.1.2-SNAPSHOT

1. The release version will be 1.1.2
2. The next development version will be 1.1.3-SNAPSHOT
3. The SCM tagged version will be artifactId-1_1_2

If you want to specify the versions manually, then you use the commands described earlier. A single line release command is good for productivity and great for automation. You can make a build plan on your Continuous Integration server with the above command to automatically tag the current version, bump the SNAPSHOT version and deploy to a repository of your choice.

Publish release to remote repository

After versioning your project, Maven can deploy, if configured, your project artifact (jar or war) to a remote repository of your choice. You can do this by using scp, webdav, sftp etc. I will descripe how to set up your pom.xml for scp and sftp.

Assume you have a Maven repository and you have SSH access to the repository, then you can publish your artifacts using scp:

When using sftp, the XML configuration looks like this

If using either scp or sftp for publishing, and having SSH as your underlying transfer mechanism, you could setup SSH without password on the repository machine. If not, Maven will ask you to enter password each time doing these operations.

Alternatively you can specify the remote repository credentials in your M2_HOME/settings.xml file. On Linux/Mac OS X operating systems you should find the file here:

> ~/.m2/settings.xml

Open the file and use these setting

As an alternative of deploying your artifacts to a remote Maven repository (i.e. those spedcified in <distributionManagement>), you could use the following command:

The command will deploy your artifacts to the directory /tmp/foo on your local machine. The command binds by default to the lifecycle phase: deploy.

Summary

Releasing software is difficult. It is usually tedious and error prone, full of manual steps that need to be completed in a particular order. Worse, it happens at the end of a long period of development when all everyone on the team wants to do is get it out there, which often leads to omissions or short cuts. Finally, once a release has been made, it is usually difficult or impossible to correct mistakes other than to make another, new release.

To make the release management process smooth, consistent and free from errors, working with a good tool is vital. Maven provides a release plugin that provides the basic functions of a standard release process. If you have work with Maven before, try it out. In the end, it will save you a lot of valuable time.

Reference

• Official Maven Release Plugin documentation

What is it?

CDI is an abbreviation of “Contexts and Dependency Injection for the Java EE platform”. First of all, I’d like to stress that CDI is not only for Java EE environments. It is equally applicable to Java SE applications, unit tests and other out-of-container environments.

The specification (JSR-299) defines its declared capabilities as follows:

This specification defines a powerful set of complementary services that help improve the structure of application code.

• A well-defined lifecycle for state-ful objects bound to lifecycle contexts, where the set of contexts is extensible
• A sophisticated, type safe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration
• Support for Java EE modularity and the Java EE component architecture—the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components
• Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a JSF or JSP page
• The ability to decorate injected objects
• The ability to associate interceptors to objects via type safe interceptor bindings
• An event notification model
• A web conversation context in addition to the three standard web contexts defined by the Java Servlets specification
• An SPI allowing portable extensions to integrate cleanly with the contain

I will walk you through all the above with samples on the upcoming Cadec 2010. In this blog entry, I’d like to give you a sense of the power of type-safe dependency injection in CDI.

Type-safe dependency injection

If you are used to Spring you know that there are basically two ways of resolving a dependency: by auto-wireing and by referencing a particular bean by name. CDI builds on the new JSR for Dependency Injection (JSR-330). Spring 3.0 implements JSR-330, so the following sample should apply to Spring 3 as well as any full CDI implementation. I’ve verified my samples using the reference implementation of CDI: The Weld container.

Type-safe dependency injection is about qualifying the requested bean among several possible ones, using annotations. Let’s look at an example: injection of Spring JMS templates. Some applications use JMS extensively. There are many JMS service endpoints to interact with and there a also JMS endpoints for dealing with QoS, like destinations dedicated for logging and destinations dedicated for inbound business messages that could not be processed. The end result is the need for a potentially large number of pre-defined JMSTemplates – one for each destination.

Some destinations may need transitions, others don’t. Oneway services will require XA support. RequestResponse services, Log services and error services will not.

Pre-CDI one would typically use configure each JMSTemplate as a named bean and then reference the name using an annotation (org.springframework.beans.factory.annotation.Qualifier)

@Autowired @Qualifier("error-dest-jmstemplate")
JmsTemplate myService1JmsTemplate;

The template XML configuration would then reference an appropriate connection factory configuration (XA, NONE-XA etc).

With CDI, there is no standardized XML / externalized configuration language. The idea is to use annotations and Java code:

private @Inject @JmsPolicy(ERROR) JmsTemplate errorQeueTemplate;

In this case, we assume that there is single JmsTemplate defined to be used to send failed inbound messages to an error destination.

@Inject simply means (JSR-330) that the field is subject for dependency injection. Autoinjection is default in CDI. There are several options for restricting the injection target among those that match the type of the field, one of being custom qualifiers. A custom qualifier is a custom annotation type that itself is annotated with the javax.inject.Qualifier annotation. Here’s the source code for the @JmsPolicy annotation that allows us to express which JmsTemplate that we expect to be injected, using the semantics of a policy:

@Qualifier
@Target( { METHOD, FIELD, PARAMETER, TYPE })
@Retention(RUNTIME)
public @interface JmsPolicy {
	JmsPolicyEnum value();
	enum JmsPolicyEnum {
		ERROR,
		LOG
	}
}

When defining the JmsTemplate bean, we will annotate it with the same “policy”, which is to say: “This JmsTemplate declaration conforms to the policy of an error destination” (timeout, Xa-support…).

The JmsTemplate factory

Since there is no external configuration language for bean instances in CDI, we will have to define the CDI correspondence of a Spring bean factory using Java annotations. In CDI, a bean factory is called a producer. A producer is implemented as a method annotated with @producer, which will return an instance of a JmsTemplate. For this simple sample, it was handy to define a single class that hosts all JmsTemplate producer methods along with declarations of the ConnectionFactories that needs to be injected into et producer method parameters:

public class JmsTemplateProducers {

	@Produces @Resource @ResourceXaPolicy(NO_XA) ConnectionFactory noxa_cf;
	@Produces @Resource @ResourceXaPolicy(XA) ConnectionFactory xacf;

	@Produces @JmsPolicy(ERROR)
	public JmsTemplate getErrorQueueTemplate(
			@JmsTemplateConfig(defaultDestinationName = "errorQueue",
					timeout = 3600)
				JmsTemplate template,
			@ResourceXaPolicy(NO_XA) ConnectionFactory cf) {
		template.setConnectionFactory(cf);
		return template;
	}

	@Produces @JmsPolicy(LOG)
	public JmsTemplate getLogQueueTemplate(
			@JmsTemplateConfig(defaultDestinationName = "logQueue",
					timeout = 100)
				JmsTemplate template,
			@ResourceXaPolicy(NO_XA) ConnectionFactory cf) {
		template.setConnectionFactory(cf);
		return template;
	}

	@Produces @Named("service1")
	public JmsTemplate getService1QueueTemplate(
			@JmsTemplateConfig(defaultDestinationName = "service1",
					timeout = 100)
				JmsTemplate template,
			@ResourceXaPolicy(XA) ConnectionFactory cf) {
		template.setConnectionFactory(cf);
		return template;
	}

	@Produces @Named("service2")
	public JmsTemplate getService2QueueTemplate(
			@JmsTemplateConfig(defaultDestinationName = "service2",
					timeout = 100)
				JmsTemplate template,
			@ResourceXaPolicy(XA) ConnectionFactory cf) {
		template.setConnectionFactory(cf);
		return template;
	}

We see another example of a producer: a field that is injected as a @resource and at the same time made available for injection into other beans (and thus being a producer).

The abstraction of policies have been used once more so that a semantic policy declaration in the form of a custom qualifier annotation could be used to specify the capabilities of the connection factory for each of the templates.

This translates into:

The service bean that processes an inbound JMS message says:

“I need a JmsTemplate that qualifies for sending error message”

The producer method for JmsTemplates that claims to support the error handling policy says: “I need a connection factory that is compatible with my policy for transaction handling, which is XA-enlisting”.

The code also shows an example of a JmsTemplate producer that support a log policy. The log policy defines a substantially shorter timeout for invocation of the log service than does the error template producer.

Finally, there are samples of JmsTemplate producers for business service endpoints (service1, service2). They are defined using a pre-defined (JSR-330) qualifier annotation type, that is convenient to use when there is no added value of abstracting the matching of an injection point with a bean.

Meta-programming in CDI

The @JmsTemplateConfig annotation used in the producer samples, is a custom annotation used in conjunction with the mata-programming capabilities of the CDI SPI, extend the annotation-based configuration language for our purpose (a real case would include all properties of the Spring JmsTemplate):

@Qualifier
@Target( { METHOD, FIELD, PARAMETER, TYPE })
@Retention(RUNTIME)
public @interface JmsTemplateConfig {
	@Nonbinding
	String defaultDestinationName() default "";

	@Nonbinding
	int timeout() default 0;
}

The annotation is processed by a class that utilizes parts of the CDI SPI for meta programming:

public class JmsTemplateConfigurationProducer {

	@Produces
	@JmsTemplateConfig
	public JmsTemplate produceJmsTemplate(InjectionPoint injectionPoint) {
		JmsTemplateConfig t = injectionPoint.getAnnotated().getAnnotation(
				JmsTemplateConfig.class);
		JmsTemplate tmp = new JmsTemplate();
		tmp.setDefaultDestinationName(t.defaultDestinationName());
		tmp.setReceiveTimeout(t.timeout());
		return tmp;
	}
}

Summary

The idea of having a 100% java-based dependency injection model, based on annotations require some innovation to take place. CDI is a good example of what it takes. CDI also raises the bar in terms of type-safe dependency injection. There are several interesting innovations to explore in CDI.

JAX-WS is the Java-standard for Web-Service XML to Java POJO binding. It entered the scene in Java EE 5 and Java SE 6. I wrote a blog entry a while back on it’s advantages over the predecessor (JAX-RPC). With WSDL-first (contract-first) design, Java POJO:s are generated from WSDL and XSD source files. The resulting Java classes and interfaces are annotated with annotations standardized by JSR-181. Thanks to the standard, JAX-WS-compliant service consumers and producers can be deployed into any Java EE 5 or Java SE 6 execution environment.

JAX-WS tooling capabilities

While JAX-WS and the associated JAX-B specifications standardize how WSDL and XSD-defined services are modeled by Java classes with annotations, they do not standardize the tooling for generating Java-classes. Thus, different JAX-WS implementations have different features in terms of how and to what detail the generation process can be controlled. As an example, the CXF wsdl-to-java generator allows more fine-grained control of how namespaces are mapped to Java packages than does the reference implementation (part of Suns Metro).

CXF to Metro

Recently, I set up a Maven project with CXF, to build a jar of JAXWS/JAXB POJOs from a WSDL with accompanying XML Schemas. The WSDL and the schemas was from different domains (business and technical domains, which I needed to keep apart in different packages. Moreover, the schemas applied different styles of namespaces (urn versus urls). The CXF tooling allowed be to take control of the package naming for each of the involved name spaces. The generated jar of binding POJOs was referenced/re-used (dependency) by several Java-based web service projects that consumed or produced the WSDL – all using the CXF JAX-WS runtime. When I was developing a Grails application, I had problems integrating CXF due to library clashes (different spring versions and xml parsers in Grails and CXF), so I decided to go for Metro in my Grails application.

Discovering the obvious

Without giving it much thought, I started to configure Metros wsimport Maven plug-in (which serves the same purpose as wsdl-2-java of CXF) for my Grails application. Intuitively, I thought I would have to use Metro tooling to generate binding classes for the Metro run-time. I turned on my brain at the point when I realized the shortcomings of wsimport, with regards to mapping name-spaces to Java packages. Why should I have to use Metro tooling? Portability of JAX-WS (thanks to JSR-181) does not only allow me to deploy to different JAX-WS run-time libraries / Java EE-containers – it also gives me the option of choing one vendors wsdl-to-java tooling over anothers! Yes, yes – obvious, but it didn’t strike me as a value until recently, I must admit. So from now on, CXF is my preferred WSDL-to-java tooling, regardless of JAX-WS implementation to be used at run-ime.

This is how CXF allows me to control name-space-to-package mappings (maven sample):

<plugins>
			<plugin>
				<groupId>org.apache.cxf</groupId>
				<artifactId>cxf-codegen-plugin</artifactId>
				<version>${cxf.version}</version>
				<executions>
					<execution>
						<id>generate-sources</id>
						<phase>generate-sources</phase>
						<configuration>
							<sourceRoot>
								${basedir}/target/generated/src/main/java
							</sourceRoot>
							<wsdlOptions>
								<wsdlOption>
									<extraargs>

										<extraarg>-p</extraarg>
										<extraarg>
											urn:se:namespace1:v1=se.callista.namespace1.v1
										</extraarg>

										<extraarg>-p</extraarg>
										<extraarg>

http://namespace2.se/v1=se.callista.namespace2.v1

										</extraarg>
									</extraargs>
									<wsdl>
										${schema.path}mywsdl.wsdl
									</wsdl>
								</wsdlOption>
						</wsdlOptions>
						</configuration>
						<goals>
							<goal>wsdl2java</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>

In Metro, I can only control the package mapping for the target namespace of the WSDL, not for the schema name-spaces. The others will be mapped to package names by default rules (which is usually in conflict with the package naming standards with a company):

<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>jaxws-maven-plugin</artifactId>
				<executions>
					<execution>
						<goals>
							<goal>wsimport</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
					<packageName>se.callista.namespace1.v1</packageName>
					<wsdlDirectory>${schema.path}</wsdlDirectory>

					<wsdlFiles>
						<wsdlFile>
							mywsdl.wsdl
						</wsdlFile>
					</wsdlFiles>

				</configuration>

				<dependencies>
					<dependency>
						<groupId>com.sun.xml.ws</groupId>
						<artifactId>jaxws-tools</artifactId>
						<version>2.1.2</version>
					</dependency>
				</dependencies>
			</plugin>

		</plugins>

In my current project we are using the JBoss Application Server. Since the project in based on EJB3 and is rather extensive we have been experiencing problems with long “deployment to test”-cycles during development. We write lots of unit tests and use a test driven approach, but we also need to do lots of integration testing in the target environment since the application is heavily AJAX based. Sitting and waiting for application deployment and application server restarts is really not only wasting valuable time, but also interruptive for the creative flow that you build up during software development. But worst of all, it takes the joy out of programming.

What we have done to minimize this problem is to introduce JavaRebel (being renamed to JRebel) together with the FileSync Eclipse plugin and exploded deployment of war archives into the development cycle. JavaRebel is a commercial tool, but I think it is very reasonable priced for what you get. What it does is that it enables reloading of Java classes on the fly. You just edit and recompile your classes in Eclipse and the changes are picked up by the target JVM (running the app-server) without a restart or application redeploy.

JavaRebel is enabled using a Maven plugin that places a rebel.xml file into all jar and war files in our application. The rebel.xml file specifies where JavaRebel should go and look for the actual class files. In our case it is in the target directories that Eclipse uses as it’s output folders. The second thing that is required is to enable a JavaRebel agent when starting the application server JVM. When the JVM is started the JavaRebel agent will start monitoring changes to classes and reload them when they are needed. It will even through plugins reload and reconfigure Spring application contexts when the xml configuration files are edited.

We use Maven as our build system, so the development cycle used to look something like this:

1. Build with maven
2. Deploy to application server
3. (wait…)
4. Test
5. Edit – and back to 1…

Now it looks like this:

1. Build ONCE with Maven
2. Deploy ONCE to application server
3. Edit/Compile/Test

The FileSync plugin is used to keep files in the exploded war archives in synch with the files in the Eclipse source folders. This enables editing in Eclipse and testing in the browser of JSP and Javascript files just by refreshing.

Keep in mind that JavaRebel does not handle all kind of file changes. If you change something that has to do with application configuration, e.g. annotations it is not picked up, but that would require a hook into the application server. You do not have to rebuild from Maven though. The only thing needed is a restart of the application server.

I definitely think that JavaRebel is a valuable, easy to setup tool that bring joy back to programming!

Continuous Integration servers have been around for quite a number of years. Mostly out of slentrian, I have stuck to CruiseControl since the alternatives (AntHill, Continuum, Hudsun, …) just haven’t been that much better to motivate me to switch.

I just attended Kuhsuke Kawaguchi’s Hudson presentation at JavaZone, and got quite a surprise. When I looked at Hudson last time (yes, it was a time ago), it was just another CI server with a nice web GUI. The presentation today showed a completely different creature. Build distribution and scalability has obviously been the focus in the Hudson team, and the latest Hudson version comes with an extremely ambitious Clustering mechanism:

• Several nodes collaborate in a Master-Slave setup, with support for at least up to 100 slaves.
• Master and slaves may run on heterogeneous hardware, with support for Solaris, most Linux dialects as well as windows.
• Slaves can be automatically configured from the Master: when a new Slave node is added, it can have a specified version of the JVM, Ant and Maven libraries downloaded and installed automatically. Using the Hudson PXE protocol, a new slave node can even boot over the network, have the operating system installed from the Master before continuing the bootstrap!
• Slave node system resources (disk space, wap space, memory etc) can be automatically monitored by the Master, and slave nodes are automatically put offline if they degenerate
• The cluster utilization itself is constantly monitored: How many nodes are busy? How long is the job queue? Using the Hudson EC2 plugin, new Slave nodes can even be allocated dynamically in the Cloud, on demand!
• You can even run other clustered applications like Hadoop or Selenium Grid on a Hudson cluster!

Wow! Not what I was looking for, but really cool stuff.

Groovy and Grails support have long been a sad story in Eclipse. Most notable, running and debugging Grails Unit tests in Eclipse has been quite painful, partly due to the fact that the Groovy eclipse plugin didn’t recognize the tests as being Unit tests (and hence the “Run as | Unit Test” has not been available), and partly because of classpath clashes between Grails and the Eclipse Groovy plugin (manifested by the dreaded ‘Disable Groovy Compiler Generating Class Files’ option, which needs to be both set and not set).

With the alpha release of V2 of the Groovy plugin, things are getting better. Most of the classpath related problems are resolved, and Groovy Unit test classes are now correctly recognized. This means Grails unit tests can now be executed directly in the IDE, without the need to run a grails command.

Some flaws with Grails Unit tests still exist, however: The Eclipse Groovy plugin is not aware of many of the Grails conventions (e.g. that all Groovy classes within the grails-app/domain folder are Domain Entities). This means that the “magic” in terms of meta-programming that Grails performs on e.g. Entities is not done when executed directly in Eclipse, which cause most of the superb Grails mocking support to fail. Consider for instance the simple Employee entity below:

class Employee {

    String name

    static constraints = {
    	name(blank:false)
    }
}

In a Unit test for the Employee, the constraint on “name” can be tested by mocking the Entity class:

class EmployeeTests extends GrailsUnitTestCase {
    void testNameNotBlank() {
    	mockDomain(Employee)
    	def e = new Employee(name: "")
    	assertFalse "validation should have fail", e.validate()
    	assertEquals "blank", e.errors.name
    }
}

This test runs as expected via the Grails command, but if executed directly within Eclipse, the Employee class is just an ordinary Groovy class that hasn’t been meta-programmed by Grails, and the test fails with the following exception:

org.codehaus.groovy.grails.exceptions.GrailsDomainException:
Identity property not found, but required in domain class [Employee]

There are ways around these problems. Starting with Groovy 1.6, AST Transformations allow meta-programming in compile time. A local AST transformation is triggered by an Annotation on the class to be transformed, and the compiler automatically applies the transformation. Most Grails meta-programming enhancements are also available as AST annotations.

Hence if we mark the Employee entity with the @Entity annotation (redundandly, since it lives in the grails-app/domain folder), the compiler will automatically transform it into a Grails entity and hence the mockDomain(Employee) mechanism will work again.

@grails.persistence.Entity
class Employee {

    ...

}

One little caveat, though: The Eclipse Groovy plugin must be configured to use the correct classpath when doing AST transformations. Otherwise, it refuses to compile the annotated class, giving the following error:

Groovy:Could not find class for Transformation Processor org.codehaus.groovy.grails.compiler.injection.EntityASTTransformation declared by
 grails.persistence.Entity

By adding a file groovy.properties with the contents as seen below to the root folder of the eclipse project, the Groovy compiler is configured to use the same classpath as the project (it sure sounds like that should be the default behaviour to me):

org.eclipse.jdt.core.compiler.groovy.groovyClassLoaderPath=%projclasspath%

Going back to the roots of OOD has been commonly advocated since Eric Evans presented his book “Domain-Driven Design: Tackling Complexity in the Heart of Software” back in 2003. There are several other sources of the movement, such as the Naked Objects Framework which we presented at Cadec 2007.

In database systems, DDD often takes its representation in a class model of the persistent information to be managed by a service or a system. If Java is used to implement the entity classes describing persistent objects, JPA may be the persistence technology (presented at several Cadecs: JPA 1.0, 2 years with JPA) used to add data base persistence behavior to the Entity POJOs.

Within DDD, the idea is to allocate all logic (as much as feasible) to the entity POJOs. This often includes logic of the following categories: accessing state (setters, getters, navigation and change of object graph), validating the state, calculation of derived attributes (calculating order sum of an order) and event processing (action-logic triggered by changes to the state of an entity, such as producing a shipment note when the order state is changed to “ready-for-shipment”).

Problem with cluttered POJOs

A challenge with DDD is to know what should go into the object model and what shouldn’t. There are many types of behavior that are specific to process or external context that – when pushed into the entity classes – makes them cluttered and potentially fragile. They become fragile, when the the forces that generate change are related to external parties rather than the core business for which the model was initially creates. Change management and dependency management becomes complex.

Groovy categories to the rescue

The Java language provides little support for dealing with this problem. qi4j is an interesting approach to deal with many aspects of POJO cluttering, but not the dependency problem. With qi4j, model objects can only be extended by making changes to the definition of Java interface of a model class. This creates dependencies between change management processes and clutters the dependencies of the entities. I think qi4j carries a lot of promise, but its evolution is bound to the limitations of the Java language, which is sometimes a problem.

In Mid 90’s, I worked with Objective-C on the NextSTEP platform. It has a construct called Category that allows a “package of behavior” (methods) to be added to an existing class in runtime. It was often used to add methods to the foundation classes (like NSString).

I’ve missed this ability in Java since I first learned it. It is how ever available in Groovy – the dynamic language built on the JDK (a Cadec presentation is available). The remaining part of this blog entry illustrates how Groovy categories can be used to extend the use of DDD without cluttering your domain model.

Our example: adding behavior to JAXB-generated POJO:s

I see Groovy typically being used in the following contexts:

• As the core development language of web application development based on the Grails framework (Callista-presentation here)
• As integration language complementing Java projects due to it’s phenomenal XML processing capabilities (dynamic DSLs through Groovy MarkupBuilder)
• As scripting language

My example for this blog is of the second category. This is the problem:

Prerequisites:

• Use JAXB-generated POJOs available in an existing jar file to parse weather data from the AccuWeather service.

The task:

• Use Groovy to create a web app that transforms the response from the AccuWeather service to an RSS 2.0 feed.

• The result should look like this (in Safari RSS reader)
  
  

Design constraints:

• DDD should be applied such that entity logic related to producing RSS output should be added to the domain objects (JAXB-generated model classes)
• All RSS-related logic should be in the same project as the logic that uses/depends on that logic. The logic should be added to the JAXB POJO:s in runtime, when needed by the Groovy RSS servlet.

The solution

We need to create a Groovy servlet that requests XML weather data from the AccuWeather weather service, parses the response into JAXB-objects produced from the XML Schema of the service and finally writes RSS XML to the servlet response by accessing the JAXB POJOs. Here’s the Servlet:

package se.callistaenterprise.labs.groovydslblog.accuatomfeed

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import javax.xml.bind.Unmarshaller;
import javax.xml.bind.JAXBContext;
import com.accuweather.weatherdata.AdcDatabaseType;
import com.accuweather.weatherdata.DayType;
import java.text.SimpleDateFormat

/**
 * Servlet that queries the AccuWeather wetherdata service and re-publishes it as a RSS feed.
 * The query string is passed on to the accuweather service as is, i.e. it is expected to be a wetherdata query string.
 * A typical query string looks like this: ?location=EUR|SE|SW005|KUNGSBACKA&metric=1
 * So that the request to this servlet (as by mapping in web.xml) becomes:
 *
 *  http://localhost:8080/accuatomfeed/AccuFeed.xml?location=EUR|SE|SW005|KUNGSBACKA&metric=1
 *
 * @author Johan Eltes
 *
 */
public class AccuAtomServlet extends HttpServlet
{
	protected void doGet(HttpServletRequest req,
            HttpServletResponse resp)
     throws ServletException,
            java.io.IOException {

		def queryString = req.queryString // We pass this on to the Accu RESTFul service

		// Get Weather Data from Accu Weather Data Service into JAXB pojos.
		Unmarshaller um = JAXBContext.newInstance("com.accuweather.weatherdata").createUnmarshaller()
		URL url = new URL("http://rdona.accu-weather.com/widget/rdona/weather-data.asp?${queryString}")
		AdcDatabaseType accuResponse = um.unmarshal(url).value

		// Produce RSS feed
		resp.contentType = "application/rss+xml"
		resp.writer << '<?xml version="1.0" encoding="UTF-8" ?>'
		def rssBuilder = new groovy.xml.MarkupBuilder(resp.writer)
		use (DayTypeRssSupportCategory, HttpServletRequestRssSupportCategory) {
			rssBuilder.rss (version: '2.0') {
				channel {
					title ("Weather stream for ${queryString?.replace('%7C','|')}")
					description("An RSS feed built with Groovy to transform the accu-wether RESTFul service into an RSS feed.")
					language ('en-us')
					link (req.rssChannelLink) // property rssChannelLink is added to HttpServletRequest by HttpServletRequestRssSupportCategory
					ttl(60)
					pubDate(new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z", Locale.US).format(new Date()))
					accuResponse.forecast.day.each {DayType day ->
						item () {
							title (day.daycode)
							link (day.url.replace('|','%7C'))
							description (day.itemDescription) // Method itemDescription is added to class DayType by DayTypeRssSupportCategory
							pubDate (day.pubDate) // Method itemDescription is added to class DayType by DayTypeRssSupportCategory
						}
					}
				}
			}
		}
	}
}

The interesting part is the “use”-keyword that in runtime applies a category that adds the method “getItemDescription” that is later invoked as if it was part of the domain class DayType (Groovy allows for property-based access to Java-beans properties as a convenience to calling get…()) .

What is then exactly a Groovy Category? It is actually just a plan Groovy class that follows a set of conventions, that allows it to be applied as a Category using the use-keyword. Here’s the category class that defines the getItemDescription() method for the DatType class:

package se.callistaenterprise.labs.groovydslblog.accuatomfeed

import com.accuweather.weatherdata.DayType
import groovy.xml.MarkupBuilder

/**
 * Adds RSS behavior to DateType
 * @author Johan Eltes
 *
 */
 public class DayTypeRssSupportCategory {

	/**
	 * Derives a RSS item description from the content of a DayType
	 * This is the old-school categories. The AST-transfomration for @Category
	 * gives much neater grammar (like Objective-C categories), but it is abit
	 * too buggy at the moment.
	 *
	 * The description is produced as html, so we need to create a local
	 * MarkupBuilder rather than passing in the parent MarkupBuilder. Otherwise
	 * the html for the description field would not be escaped.
	 */
	static String getItemDescription(DayType that) {
		StringWriter writer = new StringWriter()
		MarkupBuilder htmlBuilder = new MarkupBuilder(writer)
		writer << that.daytime.txtlong
		htmlBuilder.table {
			tr {
				td {
					img (src: "http://vortex.accuweather.com/adc2004/common/images/icons/standard/wx/45x45/${that.daytime.weathericon.padLeft(2, '0')}.gif")
				}
				td {
					ul {
						li ("Realfeel High: ${that.daytime.realfeelhigh}")
						li ("Realfeel Low: ${that.daytime.realfeellow}")
						li ("Wind direction: ${that.daytime.winddirection}")
						li ("Wind speed: ${that.windspeed} m/s")
					}
				}
			}
		}
		writer.toString()
	}

	static int getWindspeed(DayType that) {
		that.daytime.windspeed / 3.6
	}

}

Conclusions

I do think the type of construct represented by the Groovy Categories is a great way to make DDD scale for real-world-scenarios. In real-world scenarios for DDD require some way of separating concerns so that a core domain object can add value (as a first class object in the spirit of DDD).

Traditionally the solutions would involve various types of advanced patterns or frameworks. The sample used in this blog, would require the Visitor Pattern in order to keep the same level of separation of concerns and dependencies. Using qi4j is a Java-only framework solution that would solve the cluttering-problem, but still make the POJO library depend on the fact that it needs to support the needs of an RSS feed. In this specific case, when we are not in control (or pretend not to be) of the domain classes, qi4j would – to my understanding – not be useful.

With category support in the language (as in Groovy), DDD becomes much more intuitive to implement.

Try it out

I’ve attached a zip with the a maven multi project for running the sample. The zip contains one project for the feed web-app and one project that builds the jaxb model classes from the xml schema of the accu weather data response payload.

If you want to use eclipse, then issue…

mvn -Dwtpversion=1.5 eclipse:eclipse

…which generates an eclipse project for each of the maven projects. Make sure you are located in the GroovyDslBlog folder when running the command. To run/debug in Eclipse with WTP you will also need the Groovy plug-in, available here: http://dist.codehaus.org/groovy/distributions/update/ Have fun!

package se.callistaenterprise.labs.groovydslblog.accuatomfeed

import com.accuweather.weatherdata.DayType
import groovy.xml.MarkupBuilder
import java.io.StringWriter

@Category(DayType)
class AstDayTypeRssSupportCategory {

	public String getItemDescription() {
		StringWriter writer = new StringWriter()
		MarkupBuilder htmlBuilder = new MarkupBuilder(writer)
		writer << this.daytime.txtlong
		htmlBuilder.table {
			tr {
				td {
					img (src: "http://vortex.accuweather.com/adc2004/common/images/icons/standard/wx/45x45/${that.daytime.weathericon.padLeft(2, '0')}.gif")
				}
				td {
					ul {
						li ("Realfeel High: ${this.daytime.realfeelhigh}")
						li ("Realfeel Low: ${this.daytime.realfeellow}")
						li ("Wind direction: ${this.daytime.winddirection}")
						li ("Wind speed: ${this.daytime.windspeed} m/s")
					}
				}
			}
		}
		writer.toString()
	}
}

I decided to see what it would take to deploy the weather feed of my previous post to Google App Engine – a cloud platform for Java servlets. I went the maven path, so that I could simply deploy to GAE via a maven build command. In order to keep the original project independent of GAE, I set up a second web-app project as a war overlay. A war overlay project is a maven war project that that declares a dependency to another war project. Maven then merges the web artifacts of both projects into the web war produced by the depending project. An additional advantage is that I could keep the maven default layout for the original web project. GAE needs a slightly different structure, which is then used in the overlay project only.

This was useful, since GAE-specific stuff goes into a GAE-specific deployment descriptor (appengine-web.xml).

The traps

Of cause I went into a number of traps, before it all worked.

1. Script files not processed: My app uses Groovy Templates for dynamic html output. Although web.xml had a servlet mapping that matched the extension used for the templates, they were served unprocessed by GAE servlet engine. The solution was to specifically exclude them from static resources in appengine-web.xml:

   <static-files>
           <exclude path="/WEB-INF/**.groovy" />
           <exclude path="**.gtpl" />
       </static-files>

   (The app doesn’t use uncompiled groovy, but just to prepare for the future…)

2. JAXB doesn’t work in GAE, what so ever. Although I found JAXWS on the list of Java EE specs not supported by GAE, I still had a hope that plain JAXB without JAXWS network access would work. It didn’t. So I had to skip JAXB and use Groovy:s Markup builder. As a result, the DDD achieved by Groovy Categories is gone… (2010-05-15: JAXB is now a supported Java EE component)

The result

Point an RSS-reader to http://rss2weather.appspot.com and try the advertised feeds (weather for a list of places currently of interest to me).

The source projects are uploaded as well.

We are often asked to define WSDL- and schema design guidelines (contract-first) for clients. We have found a core set of guidelines that seem to work well for clients using XML_binding. The core challenge is to find a portable and reasonably useful approach to controlled evolution, supporting backwards- and forwards compatibility across service consumers and producers bound (via JAX-B or .Net binding technologies). We’ve seen the chosen approach being used fairly broadly, among others in several oasis specifications (as an example: WS-Topic in WS-Notification), but never really found a good, authoritative point of reference. Until i found this excellent document by w3c. It outlines the problem, defines a number of versioning strategies – each with an identification, and finally lists examples of standards bodies that apply the different strategies. The strategy we are endorsing is number 2.5.

Suppose you have an web application with a service layer implemented by spring beans and want to get a richer user interface ? One way to do it to use Flex.

Parts of the Flex development platform has become Open Source. What you absolutely need is addition to that is the Flex Builder. It enables debugging of the Flex application and without that you are completely lost. The license is 150 Euro so it is no big deal.

So the User Interface is produced using Flex and to take care of the remoting we can use BlazeDS which is Open Source from Adobe. BlazeDS is deployed as an web appication.

My Helloworld sample version 1 uses a simple java class on the server side. Version 2 will use spring.

The class has a method

public List<Topic> getAllTopics()

Topic contains two attributes speaker and name.

In Flex I define a RemoteObject to describe the communication with the server

<mx:RemoteObject id="server" destination="cadec-service" >
	<mx:method name="getAllTopics" result="getAllTopicsResult(event)"/>
</mx:RemoteObject>

The method tag tells Flex that whenever the getAllTopics Method is called the return value will be handled by the getAllTopicsResult method which is defined like this

private function getAllTopicsResult(event:ResultEvent):void	{
	topics = event.result as ArrayCollection;
}

It simply saves the result to a variable topics. Finally a DataGrid is defined to display the result

<mx:DataGrid dataProvider="(topics)">
	<mx:columns>
		<mx:DataGridColumn dataField="speaker" width="150"/>
		<mx:DataGridColumn dataField="name" width="350"/>
	</mx:columns>
</mx:DataGrid>

When the page is loaded a call to getAllTopics is made

<mx:Application . . . creationComplete="server.getAllTopics()">

and when the reply arrives the grid is populated and looks like this

BlazeDS need to know what the destination=”cadec-server” means. The information is supplied in a file named remoting-config.xml

<destination id="cadec-service">
     <properties>
          <source>se.callista.CadecService</source>
     </properties>
</destination>

This will create an instance of the CadecService (each time). The classes are put in WEB-INF classes.

HelloWorld sample version 2 uses spring on the server side.

To enable that I followed the instructions outlined by http://coenraets.org/flex-spring/

2 classes SpringFactory.class and SpringFactory$SpringFactoryInstance.class needs to be present att WEB-INF/classes.

To enable the spring integration these classes needs to be configured in the services-config file

<factories>
     <factory id="spring" class="flex.samples.factories.SpringFactory"/>
</factories>

Now the remoting-config.xml destination can be changed to use the SpringFactory to get the bean from spring instead of initializing it. Obviously this means that the CadedService class will only be instatiated once.

<destination id="cadec-service">
    <properties>
        <factory>spring</factory>
        <source>cadecService</source>
    </properties>
</destination>

Now everything works again.

If this wasn’t simple enough we just have to wait for the new spring/flex integration project to deliver

http://www.infoq.com/news/2009/01/spring-adobe-blazeds;jsessionid=8F49E7F3F0F00D6880768A222111D793