Measuring code quality is not a matter of a single metric. Instead, software quality has many aspects, some of which can be captured in metrics. Those metrics can be nicely assembled within a single application, which gives a nice overview of the state of an application: Sonar.

Sonar (version 1.12 at the time of writing) is a web application that can be installed standalone or inside an existing Java Web Application Container, such as Tomcat. The standalone version is quite easy to install. Just download, start and a few moments later it’s ready on port 9000.

You can capture metrics using maven by running mvn sonar:sonar on your project. In some cases, your pom.xml file will need an explicit reference to this plugin, since it is not a default apache-maven plugin.

<build>
  <plugins>
    <plugin>
      <groupid>org.codehaus.mojo</groupid>
      <artifactid>sonar-maven-plugin</artifactid>
    </plugin>
  </plugins>
</build>

After running mvn sonar:sonar on your project, Sonar will contain metrics information of your application. Browsing to “localhost:9000″ will show this.

Sonar has a nice overview screen that shows certain metrics (you can configure which ones you want to see) for all project. In a software development organization, this means that you have a single point where you can measure each project’s “technical health”. You could even add custom metrics, such as budget, number of people on the project, number of story points left in the backlog, etc.

Each project has a dashboard. The dashboard is an aggregation of more detailed metrics on a single page. This page gives a pretty good overview of the technical state of a project. When doing project reviews, this page is a good starting point to find items to investigate.

Almost every metric on the dashboard is clickable. When you click on a metric, you get more information about violating classes.

Configuring Metrics

Sonar uses findbugs, checkstyle and PMD to measure your code for bugs, ugly code and possible violation of code style policies. Sonar comes with a pretty good basic configuration, but the chance is big that you want to fiddle with the settings.

The easiest way is to take a basic configuration and make a copy of it. You can then change the configuration as you like. Note that you have to tell Sonar which projects should use this configuration.

Note that you must be logged in to be able to change the configuration. By default, there is one user, with username and password “admin”.

Another way to create a configuration is by specifically creating a new one. This is useful if you already have checkstyle, PMD and findbug configurations in your organization. You can then upload these files when creating your new configuration.

Sonar Database Configuration

The default configuration works nicely if you have Sonar installed locally and don’t mind to use the default Derby Database. For larger development environments, however, this default configuration is not enough.

You can configure Sonar to use a database quite easily. The “sonar.properties” file contains the basic Sonar configuration. Configuration examples are available for most databases. All you need to do is uncomment a block of configuration and make sure the URL, username and password are correct.

In maven, you have to configure the same URL’s. Personally, I find that a little awkward, since you need to share database details over multiple applications.

You can configure Sonar in your pom.xml file, which makes the configuration accessible to the projects using that pom. The following example configures a MySQL database.

<project>
  <properties>
    <sonar.jdbc.url>jdbc:mysql://my_sonar_db:3306/sonar?useUnicode=true&amp;characterEncoding=utf8</sonar.jdbc.url>
    <sonar.jdbc.driver>com.mysql.jdbc.Driver</sonar.jdbc.driver>
    <sonar.jdbc.username>sonar_user</sonar.jdbc.username>
    <sonar.jdbc.password>sonar_pass</sonar.jdbc.password>
    <sonar.host.url>http://my_sonar_url:9000</sonar.host.url>
  </properties>
</project>

Alternatively, you can pass all these parameters in the maven command line, or configure your maven settings.xml (on your build server, for example) to set these parameters.

Metrics don’t say it all

Although I believe that Sonar is a very nice tool to create code quality awareness, metrics don’t say it all. Some quality aspects simply cannot be caught in a metric. Just solving the issues that Sonar arises is not a good way to improve quality. Sonar can show problem area’s. It is up to the development team to find out where these problems come from, and solve them.

No matter how good the metrics are, each and every software project still needs a good process, a good project management, a hands-on architect and a smart development team to become a success.

Completely impossible? Wicket 1.5 will make this easy but is very instable for now. This article shows you how to mount pages on the root URL with Wicket 1.4. We will need to apply some hacks so hang on!

If you are only interested in using the technique you can skip to the last section ‘Understanding the demo’.

Note: when all URLs in your site start with a predictable and/or common parameter (like the locale in /en/timetable/thisweek) you are better of with URL rewriting (e.g. to /timetable/thisweek?lang=en). This article focuses on URLs that start with a very flexible word (as in http://www.hotel.com/amsterdam and http://www.tipspot.com/sarah/agenda).

Terminology

Before we dive in the details, we first need to get some terminology straight:

Mount path

A URL prefix for which you want to parse the URL in a certain way. For example /article is the mount path for all article pages.

URL mounting

Shorthand for mounting a URL strategy; e.g. calling WebApplication.mount in your Application.init method. The effect is that URLs with the given mount path are processed by the given target page.

Root mount

Mounting a URL strategy for some URLs, but without a mount path, and some given target page.

URL strategy

This term is my abbreviation for Wicket’s IRequestTargetUrlCodingStrategy; a piece of code that can parse and encode URLs. Url strategies are normally associated with a single mount path and a target page.

Root URL strategy

My term for a URL strategy that does not need a mount path to parse and encode URLs for some target page.

Tricking Wicket – the fake mount path

By default Wicket uses a mount path to select one of the the mounted URL strategies, effectively selecting a page based on the first words of a URL. This works quite well until you want an empty mount path. So how do we get around this? The trick is to fake it! Just before the URL is decoded (parsed) by Wicket we add a ‘fake’ mount path. Similarly just before a Wicket encoded URL is put in a HTML page, we remove the ‘fake’ mount path.

The advantage of this approach is that we can reuse lots of Wicket code and not have to write our own URL decoding and encoding. We simply extend the existing implementations of IRequestTargetUrlCodingStrategy (e.g. IndexedParamUrlCodingStrategy, MixedParamUrlCodingStrategy, etc.).

So that’s the basic idea. We still need to jump through some hoops to make it work.

Selecting a root URL strategy

Having a fake mount path does not give you a way to select the desired root mounted URL strategy. The fake mount path is really fake, it is only present after a URL strategy has been selected.

To enable the selection process I introduce a simple interface which our root URL strategies have to implement:

interface RootMountedUrlCodingStrategy {
  boolean accepts(String rawPath);
}

The first root URL strategy to return true will be the selected URL strategy.

We can hookup a list of root URL strategies in a custom request cycle processor. Our custom request cycle processor extends UrlCompressingWebRequestProcessor (because it gives nicer URLs for non-mounted pages) and overrides newRequestCodingStrategy to return our custom IRequestCodingStrategy which extends UrlCompressingWebCodingStrategy and overrides IRequestTargetUrlCodingStrategy urlCodingStrategyForPath(String path). For more details see the code in the demo. One thing you might notice is that the root URL strategies are only consulted when no regular Wicket mount path was detected.

Adding and removing the fake mount path

The second hoop is that we can only remove the ‘fake path’ in the encode method of IRequestTargetUrlCodingStrategy implementations, adding it in the decode method as well will confuse Wicket too much. To solve this, our custom IRequestCodingStrategy of the previous section also overrides String getRequestPath(Request request). This is slightly tricky as we do not want to touch URLs for regular mounted paths.

To complete the Wicket trickery, RootMountedUrlCodingStrategy will extend IRequestTargetUrlCodingStrategy (so that it becomes a full URL strategy) and it will be mounted on the fake mount path so that Wicket can find it to encode URLs.

Implementing RootMountedUrlCodingStrategy

Now we need to implement instances of RootMountedUrlCodingStrategy. In general what you want is behavior similar to one of the URL strategies that extend from BookmarkablePageRequestTargetUrlCodingStrategy (with subclasses like IndexedParamUrlCodingStrategy and MixedParamUrlCodingStrategy). Unfortunately the method we need to override, encode(IRequestTarget), is final. Our third hoop. Bummer.

When there is a strong need to override a method that Wicket made final (mostly with good reason), I usually just copy the Wicket class to my own sources and make sure it has the same package. Your own classes are sure to be earlier on the classpath and therefore take precedence over the classes from the Wicket jar. An infinitely better way would be to build your own version of Wicket (for example by cloning the repository on github). In the demo I just use the hacky way.

Understanding the demo

The demo is a Wicket quickstart. That means that it uses Maven 2. After you unzipped it you can do a mvn jetty:run to start it immediately. See the Wicket quickstart page to see how you hook it up in your IDE. Once that is done, just run the Start class to start the application in an embedded Jetty container. Browse to http://localhost:8080/ to see the root mounts in action.

In the code you’ll find the following packages:

nl.jteam.example

Contains the example application. For configuration see the class WicketApplication.

nl.jteam.rootmount

Contains all the code to make root mounts possible. These can be copied to your project ad verbatim.

org.apache.wicket.request.target.coding

Monkey-patch to remove a ‘final’ keyword in the Wicket code base (see comment above).

If you open WicketApplication you will notice 2 root mounts and one traditional mount. The first root URL strategy listens for ‘cities’ with an optional subject; /amsterdam and /paris/theatre and is associated with CityPage. The second root URL strategy listens for ‘members’; /alice and /bob and is associated with MemberPage. The traditional mount couples mount path tokyo to page TokyoPage. Other code wires up the custom request cycle processor.

As a bonus WicketApplication shows you how to use a ‘not found’ page from within Wicket (commented out). Take note however that this removes the fall-back request-handling of the servlet container. See the comments on how to enable it. You have been warned!

To keep things interesting ‘paris’ is both the name of a city and that of a member. The city Paris ‘wins’ because it is the first root URL strategy (see what happens if you change the order). Furthermore, ‘Tokyo’ is a recognized city. URL /tokyo will however not lead to the CityPage as traditional mounts take precedence.

Package nl.jteam.rootmount also contains a couple of base classes that take the angle out of properly implementing RootMountedUrlCodingStrategy. They are: RootMountedBookmarkablePageRequestTargetUrlCodingStrategy, RootMountedIndexedParamUrlCodingStrategy.java, RootMountedMixdedParamUrlCodingStrategy.java and RootMountedQueryStringUrlCodingStrategy.java. They correspond to the normal Wicket equivalents. All you have to do is extend them and implement boolean accepts(String rawPath). Examples are CityPageUrlCodingStrategy and MemberPageUrlCodingStrategy.

Using root mounts in your project

To apply this technique in your own application, copy the package nl.jteam.rootmount to your own project and wire it up similarly as in the demo’s WicketApplication. In addition you will need to remove a ‘final’ keyword from the Wicket class BookmarkablePageRequestTargetUrlCodingStrategy. See section ‘Implementing RootMountedUrlCodingStrategy‘ above for more information.

If you implement your own root URL strategies, take note that the accept method might be called quite often. It is prudent to make sure this method returns quickly.

Conclusion

This article shows that it is possible to have root mounts in Wicket 1.4. The downloadable demo application shows that it is even possible with a simple API. However, the implementation has to jump through some hoops to make this possible, and some of these hoops are not pretty at all.

Download the demo

wicket-rootmount-demo.tar.gz

Attendance is free, but registration is required. Read on for details.

About the meetup

The Domain Driven Design Netherlands User Group (DDDnl) organizes bi-monthly meetups where software developers, architects, product owners and managers join to discuss DDD related issues. During each meetup, one of our members gives a presentation. The upcoming meetup will cover the concept of CQRS.

Command-Query Responsibility Segregation (CQRS) is a technique developed by Greg Young that combines the Event Sourcing pattern with Domain-Driven Design. This provides various benefits, amongst others: a fully encapsulated domain model without the need for any ORM tools, separate query and reporting database, 100% correct historical information, and easy integration with other systems.

In this presentation we’ll cover the core concepts of Command-Query Responsibility Segregation, its impact on the application’s architecture, and the various advantages and disadvantages. Some (Java) code will be shown to highlight how such a system can be implemented.

Time and location

The meetup will be held at the JTeam Head Office at Frederiksplein 1, Amsterdam. Check http://www.jteam.nl/contact for directions.

You are welcome from 17:30. We will start with some food, which is expected at 18:00. The presentation starts after dinner.

Registration

You can confirm your presence by sending an email to info@dddnl.org. Please include your name and a phone number where we can reach you, just in case.

If you want to keep updated about other DDDnl meetings, make sure you register on our website: www.dddnl.org as well.

Read on to find out more.

About the Axon Framework

Axon Framework helps build scalable, extensible and maintainable applications by supporting developers apply the Command Query Responsibility Segregation (CQRS) architectural pattern. It does so by providing implementations, sometimes complete, sometimes abstract, of the most important building blocks, such as aggregates, repositories and event the bus – the dispatching mechanism for events. Furthermore, Axon provides annotation support, which allows you to build aggregates and event listeners without tying your code to Axon specific logic. This allows you to focus on your business logic, instead of the plumbing, and helps you makes your code easier to test in isolation.

Features available in 0.4

We have made quite a few additions and changes since the 0.3 release. Unfortunately, this also means I had to make some minor API changes. There is now a bigger choice of abstract classes for most of the building blocks. This allows you to choose whether you want to use the logic provided by Axon, or prefer to develop more of your own. Whatever your wish is, there should be a class to help you on your way.

The biggest change since 0.3 is the addition of an Asynchronous Event Bus that supports transactional processing of events. Since it is asynchronous, it means that your command processing doesn’t have to wait for events to be processed. However, this Event Buss can also guarantee the order in which events are delivered to the event handlers. You can choose full concurrent processing (without any guarantees about ordering), full sequential processing (FiFo guarantee) or anything in between. You could, for example, guarantee the sequential processing of Events that come from the same aggregate.

The Event Bus also provides transaction support. That means you can tell the event bus to retry an event after a certain amount of time when processing fails, for example due to an error in the underlying mechanism, such as a database. For performance reasons, you can configure the event handler to process multiple events within a single transaction. Database updates are a lot faster if you process several events within a single transaction before committing it. Within your event handler, you can configure transactions.

Besides Domain Events, Axon now also allows you to explicitly define two other types of events: Application Events and System Events. Application Event can notify your event listeners that something interesting happened in your application. System Events are a special type of application events and can be used to indicate that a part of your application has changed state, for example when the database is no longer available. These System Events could provide interesting operational information about your application.

Another major change since 0.3 is the documentation. We have brought the documentation up to par with the code-base. All features are now extensively described in the reference guide. You can download the manual from the Axon Framework website: www.axonframework.org.

Last, but definitely not least, we have created a demo application that you can easily download and deploy to have a look at how you can use events to your advantage. This demo application is built using a Flex Client and an Axon-based server side component. The Flex Client registers itself as an event listener and will automatically process incoming events, at real time! That means that you can have 2 windows open, change something in one window, and see the change come in immediately on the other window, too. Check our Sample Installation page for more information.

What to expect in upcoming releases

The major components of the CQRS pattern are already available in the 0.4 release of Axon Framework. However, there is still a number of features we want to include in the 1.0 release. Although one of the advantages of CQRS is that it makes an application scalable and extensible, the 1.0 release of Axon Framework focuses on what happens inside a single JVM. Streaming events between JVM’s is not made impossible though, the Spring Integration connectors can be used to publish events to JMS, MQ, mail, HTTP and any other protocol supported by Spring Integration.

Some features to expect before the 1.0 release are rolling snapshots. When aggregates live for a long time, the number of events to read in each time the aggregate is loaded could easily run in the thousands. Reading in a thousand events takes a long time. Instead of reading in a thousand events, you can summarize all these events into a single snapshot event. Axon Framework will provide the plumbing necessary for you to build snapshot events.

Another feature that we’ll be spending some attention on is failure recovery. Unfortunately, applications sometimes behave unexpectedly and sometimes stop entirely. The reason of a crash won’t be the Axon Framework itself, of course. But since we have a reliable source of events in the events store, we can use this to recover from failure. Axon Framework will provide some building blocks that allow you to republish events to event handlers that did not get the chance to process them. This same mechanism will allow you to restore your application state from backups.

The last feature currently on the roadmap is JMX support. Since Axon Framework deals with the dispatching and invocation of event handlers, it has interesting information about an application’s performance and technical state. We are planning to expose this information using JMX MBeans.

If you have any other ideas, you can submit a feature request on www.axonframework.org/issues.

Getting started with Axon

If you’re eager to get started using Axon Framework for your own application, check out the Axon Framework website. There, you can download the binaries, sources documentation and a sample application. If you use Maven, the reference manual will explain how you can configure the dependencies on the Axon binaries.

If the information on the website is not enough to get you started, don’t hesitate to send me a message or post a comment at the bottom of this blog entry.

A special thanks to…

Before I wrap up, I would like to thank Jettro Coenradie for his help on the sample project and the reference documentation. I think the sample turned out into a pretty cool demo environment for some of the advantages that Axon can provide.

Also many thanks to JTeam for the time they allowed me to spend on the project. Without it, I am sure I couldn’t have delivered this release. Thanks!

Introduction

First I want to describe what the Google App Engine is in a few sentences. But nobody does a better job at explaining than Wikipedia so I’ll just give you a quote instead

Google App Engine is a platform for developing and hosting web applications in Google-managed data centers. It was first released as a beta version in April 2008.
Google App Engine is cloud computing technology. It virtualizes applications across multiple servers and data centers.[1] Other cloud-based platforms include offerings such as Amazon Web Services and Microsoft’s Azure Services Platform.
Google App Engine is free up to a certain level of used resources. Fees are charged for additional storage, bandwidth, or CPU cycles required by the application.

Source: http://en.wikipedia.org/wiki/Google_App_Engine

To sum this quote up in a few words: Google App Engine is free hosting for Java! For so long technologies like PHP have been very cheap (if not free) to host. To host a Java web application on the other hand, you always have to pay good money for it. Probably the biggest reason is that for PHP, it’s easy to have many websites on one server since those websites are just a bunch of standalone scripts. A Java website on the other hand, is an entire application, so the best way to host this is to get a dedicated server with an application server installed. Dedicating an entire server to host your website usually isn’t as cheap as hosting a PHP website.

Why use the Google App Engine?

Next to the fact that Google App Engine is free to use, what else is interesting about it, you ask? Well, let me tell you! Actually, Google App Engine offers you a lot of features which can help your application in different ways. Below are a few examples of features I find the most helpful.

The dashboard

The first thing you will see when you start using the Google App Engine is the Dashboard. The dashboard has both an online version and a local development version.

The online version of the dashboard allows you to see all sorts of information about your deployed application. You can for example see application logging (filtered by INFO, WARN, etcetera), but also configured cron jobs, the content of your data store and quota details.

The local development dashboard is kind of a stripped down version of the online one. It helps you control your locally running instance of the application. Using the dashboard you can for example simulate incoming emails, simulate incoming XMPP messages and view running cron jobs.

Image service

Google offers you a service to easily manipulate images. The most common image operations are supported, like: resizing, cropping, flipping, enhancing colors and contrast.

Data store

Using Google’s JPA or JDO implementation you can access the datastore. You can also use an SQL-like query language to access the store directly.

Cron jobs / task queues

Instead of using a framework like Quartz to schedule jobs, Google App Engine takes care of executing jobs for you. You simply enter a cron-like expression and a URL to call and your job is configured.

You also have a task queue at your disposal. Your application code can add tasks to a task queue which will be executed later in the future, asynchronously. An example use case is that you don’t want clients to wait for an email to be sent before he sees the next page. Instead you can put the email task on the task queue and the email will be sent asynchronously.

Security using Google accounts

Why use a security framework like Spring Security when Google lets you use their own authentication system? When you configure your application to use Google authentication, only people with a Google account are able to login to the application. You can also configure one or more accounts to be the administrator. Administrators could have access to certain parts of the application other users can’t access.

Service for receiving email

Google offers a service that allows your application to receive emails! When an email comes in, a URL is called with the email in the POST body. The body of the request is just the plain mime message text as it was received.

Applications on the Google App Engine

To run your own application on the Google App Engine, it has to follow some guidelines in order to properly function. When I was building a sample application, I sometimes found myself writing workarounds to work with for example the JPA and mailing facilities of the Google App Engine. For the record, I was trying to use the Spring framework with JPA for persistence and Spring MVC for the frontend. I want to share the challenges I faced and how I handled them to get things working.

Sometimes I had to write custom classes to get things working, I combined all those classes in a tiny open source project called app-engine-workarounds. The project can be found at http://code.google.com/p/app-engine-workarounds/. Below I will sometimes refer to classes in this project.

Spring and the Java Mail Sender

When you’re using Spring and want to send an email from within your application, you will use the JavaMailSenderImpl which is packaged with Spring. But when running an application the Google App Engine, you can’t use this class out-of-the-box. The reason is that Google has its own email implementation and does not use SMTP servers for instance. This is why you have to interact differently with the javax.mail.* framework. Luckily you can easily extend the JavaMailSenderImpl to make adjustments. The app-engine-workaroundss library actually contains an adjusted JavaMailSender which is called the GaeJavaMailSender. This class is a drop-in replacement for the original JavaMailSenderImpl.

Handling file uploads in Spring MVC

Handling file uploads in Spring MVC requires an implementation of the MultipartResolver. The only implementation available in Spring MVC 3.0 is the CommonsMultipartResolver which uses commons-fileupload to do its job. Unfortunately the way Spring uses commons-fileupload, is not supported by the Google App Engine because it uses the file system, which Google App Engine does not provide. To make this work, you will have to utilize the streaming API part of commons-fileupload framework, which does not need the filesystem. I created my own custom implementation of the MultipartResolver that actually uses this streaming API of commons-fileupload. I put this implementation in the app-engine-workarounds library too.

Spring and JPA with transactions

You can use JPA with Spring almost like you’re used to, except that the EntityManager factory bean is configured differently. In the section “Other workarounds” on http://code.google.com/p/app-engine-workarounds/ I put a description of how to configure JPA in Spring for the Google App Engine.

Using JPA with the Google App Engine has its limitations. I only tried the JPA implementation and I soon found out that a lot of JPA features are not (yet) supported. Most of these features are related to relationships between entities. I used a relatively simply data model and already encountered the following issues:

• Multiple ManyToOne relations to the same entity is not supported
• OneToMany relation can only be used with entities that use the GAE “Key” class as the unique identifier
• Can’t operate on multiple entities within the same transaction
• In a query, you can’t use “OR” filtering referring to two different properties of an entity

Parsing inbound emails

Google App Engine offers the very useful feature of receiving emails in your application. This way users can just send an email to some address and your application processes it. When an email is received Google App Engine does a post on an URL in your application you configured. The HTTP body of the POST request contains the exact mime message as it was received by Google. To parse this mime message you can use the MimeMessage class provided by the JDK.

Unfortunately this class is not easy to use and sometimes not that straightforward at all. Usually all you want is to extract the sender, subject, body (html or plain text version) and attachments from the mime message. I created a few classes that help you to easily parse that information from a mime message received by your application. And guess what? I put these classes in the app-engine-workarounds project too! Example of how to parse an incoming email message using this class:

Session session = Session.getDefaultInstance(new Properties(), null);
MimeMessage mimeMessage = new MimeMessage(session, request.getInputStream());
EmailMessage email = new EmailMessage(mimeMessage);

// Now you can use the EmailMessage instance to easily extract information
String subject = email.getSubject();
String plainTextBody = email.getPlainTextBody();
String htmlBody = email.getHtmlBody();
Address fromAddress = email.getFromAddress();
List<Attachment> attachments = email.getAttachments();
// ... etcetera

Cronjob to keep your application “hot”

When you deploy your application it doesn’t always keep running. After like 5 minutes of inactivity, the application shuts down. Now when a user tries to access a URL, the application starts up again. So the first user that tries to open a page after a period of inactivity has to wait 30 seconds before he gets a response. Google does this to save CPU power of the servers in their “cloud”.

Especially during development, this is very annoying because it slows you down trying to test your application. What you can do is configure a cronjob with the expression “every 1 minutes” which calls the URL “/ping” (for example). When this is in place, your application always stays “hot”. In other words, it never shuts down and will always quickly respond to requests. I’m not sure if this violates any usage policy of Google, but I’m sure it’s not that bad when you only use this during development, when it’s the most annoying.

Google services as Spring beans

Google exposes a few services for you to use, but you can only get a reference to them using a static factory method. In a Spring application this is not a nice thing to do, especially because this is hard to unit test. Instead, you can configure Google services as Spring beans like this:

<bean class="com.google.appengine.api.images.ImagesServiceFactory"
      factory-method="getImagesService"/>
<bean class="com.google.appengine.api.users.UserServiceFactory"
      factory-method="getUserService"/>
...

Then you can wire one into the class that needs that service and you’re done!

Time zones

When you use JPA, any date field you’re trying to persist will get saved using the “GMT” timezone. So whenever you want to display dates you have to keep in mind to apply your own timezone to them. When you for example use the tag which comes with JSTL, you can configure the time zone in your web.xml like this:

    <context-param>
        <param-name>javax.servlet.jsp.jstl.fmt.timeZone</param-name>
        <param-value>GMT+1:00</param-value>
    </context-param>

Conclusion

On one hand Google App Engine provides a rich set of helpful features and services to help you build better applications. On the other hand you do need to compromise by working around certain issues because the Google App Engine doesn’t entirely behave as a regular application server. Also the JPA implementation in Google App Engine is very limited. But, with the workarounds in place (which I described above) you should be able to get rid of most of the frustrations you will encounter. This way you can start developing your own application like you’re used to, with the tools you’re used to but now using all the cool features the app engine offers!

Unfortunately, some frameworks won’t work at all on the Google App Engine, not even with a workaround. To quickly find out whether a certain framework will work on the app engine, take a look at this page http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine. As long as you’re not using any frameworks on the “black list” you will be fine ^^

If anyone else has workarounds or other helpful classes for the Google App Engine, let me know by posting a comment below. I will include them to this blog post and/or to the app-engine-workarounds project.

Why am I leaving JTeam you might wonder? Well to be honest JTeam deserves a new leader.

I’ve successfully brought JTeam to where it is standing right now; a well respected company full of ambitious & talented employees and satisfied clients. We continuously enjoy what we’re doing and like to share it with the world, especially with you. But each company grows, and along the way I’ve noticed that JTeam is about to enter a new phase.

A phase of professional growth, both organic and aggressive, a phase of expansion and of more exciting (inter)national challenges is beginning.

A new phase sometimes requires a new leader, and in this case, I feel it does. JTeam deserves someone who is capable of getting the maximum out of it.  Someone that has proven experience in pushing a company to the next level. And we found him.

I fully enjoyed my years in the role of Managing Director of JTeam. I’ve learned quite a lot, met a large number of awefully interesting people, succeeded in delivering some really cool projects-  but most of all, really enjoyed working with passionate people. People that always want to learn, get the most out of what they’re doing and even more important, do it with a smile and in a well respected way.

This also holds for all our clients. Along the years I’ve met many entrepreneurs and business owners all of whom had wonderful dreams, compelling ideas and exciting projects.

But the thing I like the most is meeting the people behind these ideas, dreams & projects. I sincerely hope that we helped you achieving your goal and guided you well on your never ending journey.

Some people ask me “what’s next?” and luckily I can quickly answer this question.

I simply do not know what’s next, except enjoying a well deserved holiday of – let’s say – a couple of months. I will take my time to enjoy my personal life, get some rest, read all the books I got recommended and bought and -hopefully-  will soon be conquering the skies in a helicopter!

One thing is for sure: once I’m ready, you’ll hear from me. That might take a couple of weeks, months or years. Or maybe it’ll be a matter of days. Stay tuned!

In this post, I describe some CQRS event basics and design considerations that help keep your application extensible.

The role of the domain event

In CQRS, domain events are the source of all application state changes. The diagram below shows a high-level overview of a CQRS architecture. The separation of the components that deal with commands and those that deal with queries is clearly visible.

When a command is executed, it will (most likely) change state of one or more aggregates (see DDD definition of aggregate here). As a result of these state changes, one or more events are dispatched.

These events are picked up by Event Handling Components that do whatever they were built to do. Common Event Handling components are those that update database tables in the query database, or those that send an email notification to a user. You can also use Event Handlers to execute commands on related aggregates.

The command handling component is not aware of the listeners that will act on the generated events. This is an important feature to make an application extensible. The downside is that you cannot foresee how events will be used and what information these event handlers will need.

Information contained in an event

Since events are broadcasted throughout the entire application, events should contain the information needed by the variety of possible event listeners that exist or might exist in the future. It is impossible to exactly predict what information is needed by event handling components. However, there are a few guidelines that will cover most of the cases.

Recently, someone asked me for advice on event design. He asked me if it was a good idea to use an “CustomerDetailsModifiedEvent”, which would contain the full customer details of the customer, after the change was applied. Although this sounds safe to do, it will get you in serious trouble at a later stage. I’ll go into that a little later.

Domain events should be as specific as possible. If only the address changed on a Customer, consider using an AddressChangedEvent. That event would then contain the new address. This allows components acting on these events to listen to more specific types of events. If you want to send a (paper) letter to someone if his address changed, the “CustomerDetailsModifiedEvent” won’t get you very far, as you don’t have a way to find out what exactly changed.

In some cases, it might be important to know the state as it was before the command was executed. For example, if it is vital for your application to know whether the person moved to another country (because the letter template is different in these cases, for example), then you should also provide the old address in the event. Since the event is generated by the component that also makes the actual change, this shouldn’t be too hard to implement.

public class AddressChangedEvent extends DomainEvent {

    private final Address newAddress;
    private final Address oldAddress;

    public AddressChangedEvent(Address oldAddress, Address newAddress) {
        this.oldAddress = oldAddress;
        this.newAddress = newAddress;
    }

    public Address getNewAddress() {
        return newAddress;
    }

    public Address getOldAddress() {
        return oldAddress;
    }
}

The code sample above shows the basic information contained in an AddressChangedEvent in case it is important to know the address of a customer before and after the modification. In this sample, the DomainEvent will contain information about the customer on which the address change was applied. Typically, this information is limited to the unique identifier of the aggregate.

Include the intent of the change

Let’s assume that our business case requires us to send a letter to each customer that changes address. This letter serves as some sort of validation that the address exists and gives the customer feedback that the address change was successfully handled.

In CQRS, we would just create a Event Handling Component that listens to events of type AddressChangedEvent and automatically send a letter to this customer. The information needed for the letter, such as customer name and gender are queried in the query database, since they are not contained in the event itself.

Consider an event with the following information:

AddressChangedEvent {

- aggregateId 123

- newAddress (“someStreat 2”, "13432”, “SomeCIty”) <- notice the typo in the street name

- oldAdress (…)

As a result of this event, a letter is sent. It is very unlikely that the typo in the street name will cause the letter not to arrive at the destination.

A little later, a sales representative notices the typo in the street name and want to change the address. This change will cause another letter to be sent, most likely to the same address. That’s not really the signal the business likes to send out.

In this scenario, we have captured two different intents of address changes: one is to report that a customer moved to another address, the other is to make a correction in an existing address. The way we deal with these different scenario’s is different.

Some components, like a database updaters, typically don’t care about intent. They will change the address to the new one, regardless of the reason. Furthermore, the information needed by listeners in both scenario’s is identical.

When designing events, consider making an abstract event type that defines “what” has changed. For example, an abstract AddressChangedEvent. We make it abstract, because we never want an instance of this type. This abstract then has a subclass for each intent of the change, representing the “why” of the state change. For example, AddressCorrectionEvent and CustomerMovedEvent. Since they both extend the abstract AddressChangedEvent, the both contain information about the old and new address.

Our event handling components now have a choice. If they don’t care about intent, such as the database updater, they will handle the abstract AddressChangedEvent. If they do, like our letter sender, they can listen to intent specific subclasses. In this case, the letter sender would only act on events of type CustomerMovedEvent.

Event immutability

Domain events represent a notification of a state change of an aggregate. It is a representation of something that happened. Whatever you do, what happened has happened. That said, it doesn’t make much sense to change any information in the event while it is being processed.

In CQRS, events are ubiquitous. This means that any component anywhere in the application could listen to any event. Once properties on these events start to change, it is very hard (if not impossible) to predict which component saw which information on the event.

Therefore, make sure all information contained in the event is immutable. At least from the time the event is dispatched. In java, and likely also in other programming languages, making fields immutable provide valuable multi-threading guarantees.

Event design in the Axon Framework

Recently, we released version 0.3 of the Axon Framework, an open source framework that helps you with the implementation of applications with a CQRS architecture. Axon Framework provides base implementations for most of the components that make up a CQRS architecture, such as some base classes for events.

All domain events should extend the abstract DomainEvent class. Axon will then ensure that the correct aggregate identifier is registered on the event and will also set a sequence number on the event that allows you to see in which order events were generated for an aggregate. However, the rules and guidelines mentioned above still apply to all domain events.

Starting at version 0.4 (planned for release mid February 2010), Axon Framework also provides support for Application Events and System Events. The former are events that do not represent a state change in an aggregate, but might be of importance to event handling components. The latter provide information about state changes of application components. They could, for example, report that a database is down or a mail server cannot be reached.

For more information about the Axon Framework, visit the project website: www.axonframework.org.

So I’m pleased to announce the first Dutch Lucene User Group Meetup. It will take place on 17th February (Wednesday) at the JTeam headquarters office. This first meetup will be split into two parts:

• Introduction to the user group and the members. We’ll have a discussion about what we would all like to see coming out of this user group and what activities we would like to have.
• The next part will be more technical. Anne Veling will share with us some of his experience of large scale Solr deployment that he’s working on.

If you wish to attend, please send us an email to: events@lucene-nl.org

Date: 17th February 2010

At the moment I am on a project that uses a fair amount of servers. We have more than 20 servers for the different environments and a lot of components to investigate when trying to find problems. Think about squid logs, apache httpd logs, tomcat logs and more. To make this doable, we have a syslog server.

An application running in Tomcat does not log to the system log by default. In our situation, we want our components to log to different files. Syslog has a special facility that makes it easy to do just that.

This blog post discusses the different parts of configuring system logging from a java application using the well known log4j.

syslog-ng introduction

This very short introduction is based on this article.

With syslog you can log to the local server but also to a remote server. It is also possible to do them both using a little bit of configuration. The following image gives an idea about how a logging environment can be used. (took it from the mentioned article)

Syslog consists of a few elements.

• Sources – Where can logs come from, the facilities.
• Filters – Used to for instance log events based on their severity. I used this to filter on Facility
• Destinations – Where to actually send the logs to, a file a remote host.
• Logs – Combine the sources, filters and destinations

Before we can talk about the configuration I need to tell you something about Facilities. A facility defines the source of the log. You can think about kernel messages, user-level messages, mail system and many more. The javadoc of the appender shows the possible values for these Facilities. There are also a few special facilities, these are defined as local0, local1, etc. These are the ones you can use for your own application. We use one of these for every different logfile we want.

Configure syslog-ng

The mentioned components are easily identified in the configuration of the syslog. The first thing to configure is udp access to the syslog. To enable udp logging, open the file “/etc/syslog-ng/syslog-ng.conf” and make sure to configure the sources part like the following block:

######
# sources

# all known message sources
source s_all {
# message generated by Syslog-NG
internal();
# standard Linux log source (this is the default place for the syslog()
# function to send logs to)
unix-stream("/dev/log");
# messages from the kernel
file("/proc/kmsg" log_prefix("kernel: "));
# use the following line if you want to receive remote UDP logging messages
# (this is equivalent to the "-r" syslogd flag)
udp();
};

Next up is configure the log files to which the syslog events will be send. First we configure the destination:

# destinations
destination df_local0 { file ("/var/log/cms.log"); };
destination df_local1 { file ("/var/log/site.log"); };
destination df_local2 { file ("/var/log/importer.log"); };

This code block configures three destinations with the names df_local0/1/2 and points them to the mentioned log files. Now we have to filter the incoming log events. We use the facilities that we discussed to filter the incoming events. There are lots of other options, but this is very easy to use. The following lines show the configuration of the filters.

# filters
filter f_local0 { facility(local0); };
filter f_local1 { facility(local1); };
filter f_local2 { facility(local2); };

Finally we configure the logs, these are combinations of a source, a destination and a filter.

log {
source(s_all);
filter(f_local0);
destination(df_local0);
};
log {
source(s_all);
filter(f_local1);
destination(df_local1);
};
log {
source(s_all);
filter(f_local2);
destination(df_local2);
};

Do not forget to restart the syslog service after configuration changes

Testing to see that it works

Before you start messing around with log4j, you can use a few tools to send log events to the syslog server. There are command line utilities available on all linux systems. Check this post for more information. The following command sends a message:

nc 192.168.1.1 514 <<< "<14>User Info msg from remote through TCP."

Be sure to check the port of the server (514 is the default).

Configure log4j

The final step is to send syslog events from your java application. Log4j comes out of the box with a SyslogAppender. There is one requirement to be able to use log4j with sys logging. You need to have udp enabled like we discussed in the configuration section. Most of this comes from the mentioned blog post.

An example of log configuration for log4j :

log4j.rootLogger=INFO, SYSLOG

log4j.appender.SYSLOG=org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.syslogHost=127.0.0.1
log4j.appender.SYSLOG.layout=org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.conversionPattern=%d{ISO8601} %-5p [%t] %c{2} %x - %m%n
log4j.appender.SYSLOG.Facility=LOCAL1

That is it, now you have a java application logging to the syslog. Feedback about improvements is welcome.

In this post I will explain how we use Spring Integration to migrate content, handle errors, measure performance and deal with the fact that content could contain references to other content that is not imported yet.

Short Spring Integration introduction

As I cannot explain Spring Integration in a few sentences, I will just focus on the elements that I use in the example. To get a complete overview of the elements I recommend you to read the reference manual.

• Message – Generic container for data. It contains the payload which can be any object.
• Message Channel – Used for transporting the data between the different elements.
• ChannelAdapter – Message Endpoint that enables connecting a single sender or receiver to a channel.
• Transformer – Enables the loose-coupling of Message Producers and Message Consumers by transforming a message to another type.
• Service activator – The endpoint type for connecting any Spring-managed Object to an input channel so that it may play the role of a service.
• Router – Provides a simple way to connect a router to an input channel.
• Splitter – Partition a message in several parts, and send the resulting messages to be processed independently.

Getting the content

Before you can start importing the content, you of course need to scrape the content from the different websites. In our case this is done by the guys from Kapow. They provide us with a lot content that is preformatted in XML files so that our import tool can handle the incoming requests. The content is distinguished by the type of document. So for example we could have news, address, a brochure and many more. The different types of documents contain data like images, videos, PDF files and of course text. Each XML file contains an element that represent a unique id for that file. This is used to identify any existing documents in the CMS.

Connecting to the repository

Hippo CMS is created on top of the Apache Jackrabbit repository. We connect directly to the repository using the Hippo Repository Connector that is provided in the Hippo Site Toolkit. This enables us to interact with the repository and provides us the possibility to perform actions like storing, editing and finding nodes.

My colleague Jettro Coenradie has written a blog post that goes more in-depth about connecting to the Hippo Repository.

Process overview

Starting point

As you can see in the image we provide two ways for Kapow to deliver the content. One is via web services and the other one is directly via the file system (as Kapow runs its tool on the same server as the importer). This has few reasons:

1. Web services provides more flexibility for other applications to connect with the importer tool.
2. Using the web service will prevent the problem that Spring Integration tries to read the file before it is completely written to the file system.
3. When the web service is not available, Kapow is still able to write the XML files directly to the file system.

Webservice

Spring Integration provides us with a inbound web service gateway that send a message to a channel that is received from a Web Service invocation.

As you can see in the process overview image, messages that are received from the web service are enriched with the filename and then written to the file system. We have to do this in order to create an XML file (using the transformer) which obviously needs a filename. With the file outbound gateway the XML file is placed in the directory that is scanned for new files.

To make this all work we have to configure in the Spring WS servlet the endpoint mapping that know which request needs to map to our gateway that is configured in our integration context.

When the process is finished with writing to the file system and therefore correctly received by the importer we use a service activator that returns a ResponseMessage with the text “OK”. This response message is received by Kapow.

The endpoint configuration in the web service servlet:

    <bean id="endpointMapping" class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
        <property name="mappings">
            <props>
                <prop key="{http://www.jteam.nl/pons/webservice}AddressRequest">webserviceGateway</prop>
                <prop key="{http://www.jteam.nl/pons/webservice}NewsRequest">webserviceGateway</prop>
            </props>
        </property>
    </bean>

The integration configuration:

<si-ws:inbound-gateway id="webserviceGateway" marshaller="unmarshaller" request-channel="transformedIncomingRequestBuffer" />

<si:channel id="transformedIncomingRequestBuffer" />

<si:transformer ref="headerEnricher" output-channel="enrichedUnmarchalledInputFile" input-channel="transformedIncomingRequestBuffer" />
<si:channel id="enrichedUnmarchalledInputFile" />

<si-xml:marshalling-transformer marshaller="unmarshaller" output-channel="unmarchalledInputFile" input-channel="enrichedUnmarchalledInputFile" result-transformer="toStringTransformer" />
<si:channel id="unmarchalledInputFile" />

<file:outbound-gateway request-channel="unmarchalledInputFile" reply-channel="handledFile" delete-source-files="false" directory="$si{file.import.path}" />

<si:channel id="handledFile" />

<si:service-activator ref="tempHandler" input-channel="handledFile" />

<bean id="headerEnricher" class="nl.jteam.importer.HeaderEnricher" />
<bean id="tempHandler" class="nl.jteam.importer.ResponseMessageHandler" />

Transform file

All the XML files are written to the file system in a given directory. With the inbound-channel-adapter element the files are read from the given directory. You can provide a filter that only accepts the types based on the known suffix. In our case the only files we want to read are XML files. The poller is used to configure how the maximum messages we want per poll and on what interval it needs to scan the directory for new files.

The file-to-string-transformer element transforms, as the name already suggests, a file to a string. This string is then used by the unmarshalling-transformer as input for the unmarshalling process to create JAXB objects.

<file:inbound-channel-adapter id="fileAdapter" directory="$si{file.import.path}" filter="patternMatchingFileListFilter" channel="fileInputChannel">
    <si:poller max-messages-per-poll="$si{file.poller.maxperpoll}">
        <si:interval-trigger time-unit="MILLISECONDS" interval="$si{file.poller.interval}" />:         <si:interval-trigger time-unit="MILLISECONDS" interval="$si{file.poller.interval}" />
    </si:poller>
</file:inbound-channel-adapter>
<si:channel id="fileInputChannel" datatype="java.io.File" />

<file:file-to-string-transformer output-channel="xmlInputChannel" input-channel="fileInputChannel" charset="UTF-8" delete-files="true" />
<si:channel id="xmlInputChannel" />

<si-xml:unmarshalling-transformer id="defaultUnmarshaller" output-channel="docTypeChannel" input-channel="xmlInputChannel" unmarshaller="unmarshaller" />

<bean id="patternMatchingFileListFilter" class="org.springframework.integration.file.PatternMatchingFileListFilter">
    <constructor-arg value=".*\.xml" />
</bean>

<bean id="unmarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
    <property name="marshallerProperties">
        <map value-type="java.lang.Boolean" key-type="java.lang.String">
            <entry key="jaxb.formatted.output" value="true" />
        </map>
    </property>
    <property name="contextPaths">
        <list>
            <value>nl.jteam.importer.jaxb.news</value>
            <value>nl.jteam.importer.jaxb.address</value>
        </list>
    </property>
    <property name="schemas">
        <list>
            <value>classpath:/xsd/news.xsd</value>
            <value>classpath:/xsd/address.xsd</value>
        </list>
    </property>
</bean>

Document router

To identify which handler class needs to handle the document that is being imported, we created a router. This router gets the name from the payload and returns this value. This value than can be used to determine the channel to put the message on. So when the name of the payload is News it will use the channel with id News to put the message on.

The configuration:

<si:channel id="docTypeChannel" />

<si:router ref="docTypeRouter" input-channel="docTypeChannel" method="resolveObjectTypeChannel" />
<si:channel id="News" />
<si:channel id="Address" />

<si:service-activator ref="newsMessageHandler" output-channel="newContentItemNotification" input-channel="News" method="handleMessage" />
<si:service-activator ref="addressMessageHandler" output-channel="newContentItemNotification" input-channel="Address" method="handleMessage" />

<bean class="nl.jteam.importer.DocumentTypeMessageRouter" name="docTypeRouter" />

The implementation of the router class:

public class DocumentTypeMessageRouter {

    public String resolveObjectTypeChannel(Message message) {
        return message.getPayload().getClass().getSimpleName();
    }
}

Handlers

Each document type has his own handler class. This class is responsible for handling all the properties that are relevant for that document.

A document in Hippo CMS is a JCR node in the repository. The handler will create this node if it not already exists. If it does exist it will take that node. Because the content from the XML is the correct content, all properties and child nodes will be removed. So any change that is made to the content via the CMS in that document will be gone. Because we keep the node, references in the repository by other nodes will be intact, but all properties will be recreated by the handler.

For each property the handler will add this to the node or calls another handler that handles that specific property such as an image handler or audio handler class.

Missing links

It could be that a document has references to another document that is not imported yet. This means that the link cannot be created yet. To solve this problem we store for each link that cannot be created a missing link node in the repository. This node contains the information that is necessary to create the link when that document is imported. I will explain later on how the missing links are used when updating content.

When the handler is finished with creating a document in Hippo CMS, it will execute a query that finds all the documents that contain a reference to the imported document or in other words, it will find all missing links that now can be resolved.

Referred documents splitter

The outcome of the query that looks for references to the imported document could return multiple documents of different types. For example, we have imported an address document and that document is referenced by a news item and a press release item. These two documents will each be represented in a ReferredDefinition object. These ReferredDefinition objects contain the information of the missing link node plus the unique repository id (uuid) of the currently imported document.

Spring Integration provides us a splitter that has the capability to partition the message in several messages. The implementation of our splitter receives a list of ReferredDefinition objects. Each message (ReferredDefinition object) will be send to a router that routes the ReferredDefinition object to his appropriate channel.

The configuration:

<si:channel id="newContentItemNotification" />

<si:splitter ref="referredBySplitter" output-channel="referedBy" input-channel="newContentItemNotification" method="splitReferredDefinitions" />

<bean class="nl.jteam.importer.ReferredByMessageSplitter" name="referredBySplitter" />

The referred by message splitter class:

public class ReferredByMessageSplitter {

    public List<referreddefinition> splitReferredDefinitions(List<referreddefinition> referedDefinitions) {
        return referredDefinitions;
    }
}

Referred by router

The splitter provides the router with a single ReferredDefinition item. The ReferredDefinition object contains information about the document type that needs to be updated. The implementation of the router is quite simple. It gets the type of the document that needs to be updated and adds the string “Update” to the document type. This combination gives us the name of the channel that is used to put the message on.

The configuration:

<si:channel id="referredBy" />
<si:router ref="referredByRouter" input-channel="referredBy" method="resolveItemChannel" />

<si:channel id="NewsUpdate" />
<si:channel id="PressReleaseUpdate" />

<bean class="nl.jteam.importer.ReferredByMessageRouter" name="referredByRouter" />

The referred by message router class:

public class ReferredByMessageRouter {

    public String resolveItemChannel(ReferredDefinition referredDefinition) {
        return referredDefinition.getPrimaryTypeReferredBy() + "Update";
    }
}

Update handlers

Each document type has just like the normal handlers his own update handler. The update handlers are used for updating content that has a reference to the imported document. The handler receives in ReferredDefinition object which contains the information of the document that contains the reference.

So if we have for example two documents (A and B). B is a news item that contains a field addres and A is an address document. Document B is already imported and has a reference to A. Document B links to document A, but because A was not imported yet, a missing link node for A exists. Now document A is going to be imported, so document B can be updated with a working link. The content handler of A finds the missing link and creates a ReferredDefinition object with the information of the missing link. The update handler finds document B based on his unique id that is also stored in the ReferredDefinition object.

Now that document B is found, the update handler can add the correct property (which is specified in the ReferredDefinition object) to document B with the link to document A. When the link is created, it is no longer necessary to keep the missing link node and will therefore be removed.

Error handling

When importing content errors could occur. We distinguish between two types of errors:

1. Critical errors – Something is wrong with the XML structure or with the connection to the repository.
2. Non critical errors – Errors like incorrect content or links that cannot be created.

When a critical error occurs it means that we cannot import that document at this moment. So we have defined an error channel that is used to put the payload on and transform it back to an XML file. That file is than written to a different  folder, so that it will not be picked up again by Spring Integration.

With non critical errors it is only necessary to notify a system admin that something went wrong. So in order to do this, we introduced an error collector. This error collector is nothing more than object that contains a list of errors and a little information about the document. This collector is passed through the whole process of importing a document and all errors that occur will be collected. At the end of that process the errors will be mailed to the system admin. Currently this is done after each document, but this will probably change in the future to use some sort of batch mailing.

<si:channel id="errorChannel" />

<si:chain input-channel="errorChannel">
    <si:service-activator ref="errorMessageHandler" method="handleMessage" />
    <si:router ref="errorMessageRouter" method="routeByPayloadType" />
</si:chain>

<si:channel id="errorOutputChannel" />
<si-xml:marshalling-transformer id="defaultMarshaller" marshaller="unmarshaller" output-channel="xmlOutputChannel" input-channel="errorOutputChannel" result-transformer="toStringTransformer" />

<bean id="toStringTransformer" class="org.springframework.integration.xml.transformer.ResultToStringTransformer" />

<si:channel id="xmlOutputChannel" />

<file:outbound-channel-adapter directory="$si{file.unhandled.path}" channel="xmlOutputChannel" />

<bean id="errorMessageHandler" class="nl.jteam.importer.errorhandling.ErrorHandler">
    <property name="errorMailer" ref="errorMailer"></property>
</bean>

<bean id="errorMessageRouter" class="nl.jteam.importer.errorhandling.ErrorMessageRouter">
    <property name="objectChannel" ref="errorOutputChannel"></property>
    <property name="xmlChannel" ref="xmlOutputChannel"></property>
</bean>

Performance

With the use of an aspect we send a message to the performanceMonitor channel. When you declare a MessageChannel you can call the method send(..) to send your message to the channel. In our case we create a new StringMessage to send the performance message. The channel is used by the service-activator. The service-activator uses a poller to throttle inbound messages.

The service-activator passes the message to the Log4jMonitorPersister, where it logs the message.

The configuration:

<si:channel id="performanceMonitor">
    <si:queue />
</si:channel>

<si:service-activator ref="monitorPersister" input-channel="performanceMonitor" method="persist">
    <si:poller max-messages-per-poll="100">
        <si:interval-trigger time-unit="MILLISECONDS" interval="10000" />
    </si:poller>
</si:service-activator>

<bean id="monitorPersister" class="nl.jteam.importer.monitoring.Log4jMonitorPersister" />

<aop:aspectj-autoproxy />

<bean id="monitoringHandlersAdvice" class="nl.jteam.importer.monitoring.MonitoringHandlersAdvice">
    <property name="performanceMonitor" ref="performanceMonitor"></property>
</bean>

The MonitoringHandlersAdvice class:

@Aspect
public class MonitoringHandlersAdvice {

    private MessageChannel channel;

    @Around("execution(* nl.jteam.importer.handler.*Handler.handleMessage(..)) && args(message)")
    public Object monitorB(ProceedingJoinPoint proceedingJoinPoint, Message message)
            throws Throwable {
        String fileName = (String) message.getHeaders().get("springintegration_file_name");
        Object payload = message.getPayload();

        StopWatch clock = new StopWatch();
        DateTime start = new DateTime();

        try {
            clock.start(proceedingJoinPoint.toShortString());
            return proceedingJoinPoint.proceed(new Object[]{message});
        } finally {
            clock.stop();
            StringBuilder outMessageBuilder = new StringBuilder();
            outMessageBuilder.append(clock.getTotalTimeMillis()).append(";")
                    .append(payload.getClass().getSimpleName()).append(";")
                    .append(fileName).append(";")
                    .append(start.toString("yyyy-MM-dd HH:mm:ss"));
            channel.send(new StringMessage(outMessageBuilder.toString()));
        }
    }

    @Required
    public void setPerformanceMonitor(MessageChannel performanceMonitor) {
        channel = performanceMonitor;
    }
}

The Log4jMonitorPersister class:

public class Log4jMonitorPersister implements MonitorPersister {
    private final static Logger log = LoggerFactory.getLogger(MonitorPersister.class);

    @Override
    public void persist(String monitorEvent) {
        log.info(monitorEvent);
    }
}

Conclusion

I have showed you how we use Spring Integration to migrate XML content to Hippo CMS. As you could see the configuration is relatively simple and when we want to import a new content type, all we have to do is create a handler and wire up the configuration. As always SpringSource provides good documentation that makes is easy work with Spring Integration.

References

Spring Integration: http://static.springsource.org/spring-integration/reference/htmlsingle/spring-integration-reference.html