Spring – Caching Java methods

Caching has become an increasing concern for developers wanting to increase performance but still utilize the flexibility of Web services in their applications. There is no doubt that Web Services are extremely versatile, but the HTTP protocol combined with the marshalling and unmarshalling of SOAP, assuming you aren’t using a REST web service, is very slow and doesn’t perform very well.

The answer for most of this has come in the form of caching. I have used EHCache, my favorite open source Java caching framework on several projects in the past 3 years and I’ve used it in many different ways to increase the performance and response times of Ajax applications. Using a cache is not for the inexperienced. You can easily go overboard and degrade performance by utizing too much memory. Deciding what to and what not to cache should be a decision by your entire development team and agreed upon before implementation. I do not recommend letting a single developer run wild with a cache in hand. It’s probably just as dangerous as running with scissors.

Spring has many different way to handle integration with caching frameworks, including EHCache. Hibernate also supports many caching implementations and I use those as well. For spring 2.5 and below, there is even a library that specifically gives you the ability to use special tags in your context files to handle caching of data.

In this particular example, we are going to look at how we can use Spring, AOP and EHCache to cache the returned data of a java method, so that you don’t actually have to write the code to manage storing the objects in the cache yourself.

<beans xmlns="http://www.springframework.org/schema/beans&quot;
     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
     http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
     http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
     http://www.springframework.org/schema/security  http://www.springframework.org/schema/security/spring-security-3.0.xsd
     http://www.springmodules.org/schema/ehcache http://www.springmodules.org/schema/cache/springmodules-ehcache.xsd”&gt;

 <!–  this only works in Spring 2.5 currently and you need a special third-party jar as well.

        <ehcache:caching id="getDistributedCache"
                cacheName=”distributedCache” />






 There is the configuration and now we need a class to actually do the caching work. If you noticed above you can indicate which methods in a Spring Bean get cached by specifying a regular expression matching pattern. So for example, you could have a service class that returns a User (getCachedUser) and in your configuration .*Cached.* to match any spring bean with any method with Cached in it’s name.

import java.io.Serializable;

import net.sf.ehcache.Cache;
import net.sf.ehcache.Element;

import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.util.Assert;

    public class MethodCacheInterceptor implements MethodInterceptor, InitializingBean {
      private static final Log logger = LogFactory.getLog(MethodCacheInterceptor.class);

      private Cache cache;

       * sets cache name to be used
      public void setCache(Cache cache) {
        this.cache = cache;

       * Checks if required attributes are provided.
      public void afterPropertiesSet() throws Exception {
        Assert.notNull(cache, “A cache is required. Use setCache(Cache) to provide one.”);

       * main method
       * caches method result if method is configured for caching
       * method results must be serializable
      public Object invoke(MethodInvocation invocation) throws Throwable {
        String targetName  = invocation.getThis().getClass().getName();
        String methodName  = invocation.getMethod().getName();
        Object[] arguments = invocation.getArguments();
        Object result;

        logger.debug(“looking for method result in cache”);
        String cacheKey = getCacheKey(targetName, methodName, arguments);
        Element element = cache.get(cacheKey);
        if (element == null) {
          //call target/sub-interceptor
          logger.debug(“calling intercepted method”);
          result = invocation.proceed();

          //cache method result
          logger.debug(“caching result”);
          element = new Element(cacheKey, (Serializable) result);
        return element.getValue();

       * creates cache key: targetName.methodName.argument0.argument1…
      private String getCacheKey(String targetName,
                                 String methodName,
                                 Object[] arguments) {
        StringBuffer sb = new StringBuffer();
        if ((arguments != null) && (arguments.length != 0)) {
          for (int i=0; i

        return sb.toString();

With this example, you can see how generic you can make you caching. You may also want to tweak the ehcache settings as well. Ehcache is extremely configurable. You have many many options. Notice that above we specified a configuration file of ehcache-CacheService.xml. In this file we’ll take care of adding the caches that we want to use. Ehcache support replication via RMI, JMS and JGroups. This example replicates the cache among nodes in the cluster using RMI. Each node is discovered on it’s own so this file is the same on every server.

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
         xsi:noNamespaceSchemaLocation=”ehcache.xsd” >



                                    peerDiscovery=automatic, multicastGroupAddress=,
                                    multicastGroupPort=4446, =32″/>

                        multicastGroupPort=4446, timeToLive=1″


                    propertySeparator=”,” />


     <cache name="org.company.cache.METHOD_CACHE"

     <cache name="distributedCache"


Hibernate Validation latest and greatest

I recently decided to upgrade my Hibernate Validator code and discovered that the framework had changed quite a bit in 4.0.2 to support the new Java validation API. I wanted to share some of my code in the hopes that it would help some of you become familiar with how to use this framework.

The framework itself still pretty much works the same way for annotating your Hibernate classes, it’s the programmatic validation and the custom validators that are different. Let’s look at an example from a Hibernate class. Remember that you are not restricted to using the validation framework with just Hibernate classes. It’s just that with Hibernate annotated classes the validation occurs automatically before the database is hit. You don’t have to manually validate when using Hibernate ORM.

@NotNull //enforce that this cannot be null
@NotEmpty //enforce it cannot be an empty string
@Column(name=”username”, nullable=false)
public String getName() {
return name;

public void setName(String name) {
this.name = name;

Let’s assume that we want to call a validation on this class manually. I added a method to my GenericDAO to accomplish this, but you could do this anywhere you like. I prob should have lazy initialized this, but for the sake of example, I’ll just mention what I should have done.

protected GenericDAO(final Class type) {
this.type = type;

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();


public Set> validate(final T t) {

return validator.validate(t);


You can also use the validator in Spring by using the @Valid annotation. Learn more


public String create(@Valid User user, BindingResult result) {
if (result.hasErrors()) {
return "user/createForm";
//process adding a user here
//do something
return "redirect:/user/" + user.getId();

Now we can use an instance of the UserDAO to validate our object.

UserDAO userDAO;

User user = new User();


This method will return a Collection of ConstraintViolation so that you can process and do what you want with the result. I created a method in a utility to format and return the result. It’s not elegant, but it works.

public static String formatViolations(Set violations) {

StringBuilder sb = new StringBuilder();
for (ConstraintViolation violation : violations) {

sb.append(“Property: ” + violation.getPropertyPath() + “\n”);
sb.append(“Message: ” + violation.getMessage() + “\n”);
sb.append(“Value ” + violation.getInvalidValue() + “\n”);
sb.append(“Entity ” + violation.getLeafBean() + “\n”);

return sb.toString();


That’s all pretty simple and as you could see, this mechanism could work on any class. Remember there are many different annotations for validation, including but not limited to @Size, @Length, @Email etc…

Aside from usual suspects in the out of the box validation implementation, you also have the ability to create your own. This is where I had to rewrite some of my old code to migrate to the latest validations framework.

Let’s look at a validation I created to enforce rules on passwords by a specified strategy. First we have the annotation @Password that we can apply to a password String field of our User object.

@Constraint(validatedBy = PasswordValidator.class)
public @interface Password {

PasswordStrategy strategy() default PasswordStrategy.NO_STRATEGY;

String message() default “{validator.invalid_password}”;

Class[] groups() default {};

Class[] payload() default {};


Now we need the Strategy that we can pass to the annotation to specify which strategy we want to enforce in your application. This class will get ahold of a custom ValidationMessages.properties that is at the root of our classpath to process some messages. It looks complicated, but explaining how it works is beyond the scope of this document.

import java.util.ResourceBundle;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public enum PasswordStrategy {

NO_STRATEGY(“.*”, 0, “validator.invalid_password.NO_STRATEGY”),
DIGIT_STRATEGY(“\\d[0-9]”, 0,”validator.invalid_password.DIGIT_STRATEGY”),
STRONG_STRATEGY(“^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d.*\\d)[a-zA-Z0-9.!@#$%^&*()\\s]{6,30}$”, 0, “validator.invalid_password.STRONG_STRATEGY”),
PASSPHRASE_STRATEGY(“^(?=.*[a-z])(?=.*[A-Z])(?=.*[\\s])[a-zA-Z0-9\\s]{6,30}$”, 0, “validator.invalid_password.PASSPHRASE_STRATEGY”),
USERID_STRATEGY(“^[a-zA-Z0-9.!@#$%^&*()\\s]{6,30}$”, 0, “validator.invalid_userid.USERID_STRATEGY”);

public String toString() {

return getMessage();

PasswordStrategy(String pattern, int flags, String message){
this.pattern = pattern;
this.flags =flags;
this.message = message;


private final String pattern;
private final int flags;
private final String message;
private Pattern patternRegEx;

public String getMessage(){

String thisResult = ResourceBundle.getBundle(“ValidationMessages”).getString(message);
return thisResult;


public boolean validate(Object value) {
patternRegEx = Pattern.compile(
flags );

if ( value == null ) return true;
if ( !( value instanceof String ) ) return false;
String password = (String) value;
Matcher m = patternRegEx.matcher( password );
return m.matches();

Now we need the Password annotation implemetation.

public class PasswordValidator implements ConstraintValidator {
private PasswordStrategy strategy;

//part of the Validator contract,
//allows to get and use the annotation values
public void initialize(Password parameters) {
strategy = parameters.strategy();

public boolean isValid(String value, ConstraintValidatorContext constraintContext) {

return strategy.validate(value);


Now we can apply our validation to our User class. Note that we chose the STRONG_STRATEGY that will map to the Regular expression in the PasswordStrategy class.

@Column(name=”password”, nullable=false, insertable=false, updatable=false)
public String getPassword() {
return password;

public void setPassword(String password) {
this.password = password;

Now here is our ValidationMessages.properties

validator.invalid_password.NO_STRATEGY=The password is invalid
validator.invalid_password.DIGIT_STRATEGY=Your password must be digits
validator.invalid_password.STRONG_STRATEGY=A valid password is a minimum of six characters and a maximum of thirty. It should contains at least one lower case letter, one upper case letter and two digits. Make your password stronger by using a special character (.!@#$%^&*) or by including separate words
validator.invalid_password.PASSPHRASE_STRATEGY=A valid password passphrase is a minimum of six characters and a maximum of thirty. It should contains at least one lower case letter, one upper case letter and contain multiple words
validator.invalid_userid.USERID_STRATEGY=A Valid user id must be a minimum of 6 characters and no more than 30
javax.validation.constraints.AssertFalse.message=must be false
javax.validation.constraints.AssertTrue.message=must be true
javax.validation.constraints.DecimalMax.message=must be less than or equal to {value}
javax.validation.constraints.DecimalMin.message=must be greater than or equal to {value}
javax.validation.constraints.Digits.message=numeric value out of bounds (. expected)
javax.validation.constraints.Future.message=must be in the future
javax.validation.constraints.Max.message=must be less than or equal to {value}
javax.validation.constraints.Min.message=must be greater than or equal to {value}
javax.validation.constraints.NotNull.message=may not be null
javax.validation.constraints.Null.message=must be null
javax.validation.constraints.Past.message=must be in the past
javax.validation.constraints.Pattern.message=must match “{regexp}”
javax.validation.constraints.Size.message=size must be between {min} and {max}
org.hibernate.validator.constraints.Email.message=not a well-formed email address
org.hibernate.validator.constraints.Length.message=length must be between {min} and {max}
org.hibernate.validator.constraints.NotEmpty.message=may not be empty
org.hibernate.validator.constraints.Range.message=must be between {min} and {max}

This file is a copy of the default one included in hibernate itself. I have customized it a bit. I don’t consider localization in this application, but considering multiple language isn’t that difficult using this framework.

The new hibernate 4.0.2 validation mechanism is compliant and inline with the Java Validation Framework defined in JSR303. This was a great step in getting on a common validation framework. If you are starting a new project with Hibernate or just want to use a validation mechanism, Hibernate Validator 4.0.2 or greater is the place to start.

Implementing Hudson Server

By Chris L Hardin
Sr. Software Architect

Hudson is without a doubt the best tool I have used this year in my projects. Continous integration is very important in an Agile development environment, but it most often involves developers committing time and effort into making it happen and it’s a consistent effort that never seems to end. Hudson and Cruise Control are two solutions that change all that.

Let me preface this by saying that I started out using Cruise Control for a month and I then I tried Hudson and in just a few hours, I had removed Cruise Control and I never looked back. Cruise Control has it’s merits but Hudson has all the same functionality plus much much more. I highly recommend the migration if you are still stuck with Cruise Control.

Hudson is a Java project that you can deploy standalone or in a web container like Tomcat. It supports building multiple types of projects and tasks and it has a few hundred plugins to customize its functionality. Hudson is a great tool out of the box, but once you browse and install a few plugins, it really comes into it’s own.

I spent 5 minutes installing Hudson into Tomcat and then I created a new project through the interface. In the configuration, you can tell Hudson where your project is, SVN, CVS, etc. You set how you build your project, whether it is Maven or Ant and then you are off. Hudson has no limits to the configuration options. You can configure it to poll your version control periodically to look for changes, or build every so often or you can build on demand only. You can configure the project to automatically deploy to a container, publish to a repository and archive your builds.

In a project where I used Hudson, I set a series of projects to build periodically by polling SVN and if there was a change, it would trigger a chain of projects to build to create the final project and deploy the enterprise to a container.

Hudson requires a dedicated server. You don’t really want to run this on your desktop. My recommendation is take a decent Linux machine and dedicate it to running your builds and give it plenty of disk space to archive your builds.

Hudson also integrates with tools such as Polarion, ViewCVS and WebSVN to give you reports and link back from changes to see the source. It also will aggregate reports from several sources including Junit reports, TestNG reports, Checkstyle reports, Crap4j and more. Again this is where the plugins are key.

Hudson is easy to maintain and upgrade. Just make sure your HUDSON_HOME environment variable is set to a location where you want all the work to happen and make sure that location is redundant. Don’t store anything under the hudson directory that gets created when the container starts. To upgrade, just simple replace the hudson directory and war file and start your container and that’s it.

Installing a plugin is as simple as going to the plugin page of the Hudson management screen and choosing the plugins you want and download. It will also let you know when there is a new version of an installed plugin.

Hudson will also cluster together multiple machines and allow you to control them from a single instance. You just add machines as slaves by running the slave.jar on the machines you want to cluster and tell the master Hudson instance where these are. When builds run, Hudson will utilize resources on the other machines to accomplish builds as well as the master machine. This functionality isn’t as useful if you have projects that depend on each other. I recommend avoiding having projects depending on others if you can but this is often impossible since all projects should inherit from a set of common framework projects in an enterprise to avoid code duplication and promote reuse.

Hudson has a robust email and notification mechanism with keeping up with build statuses. You can configure emails to be sent to a group on success, emails to be sent to developers who are the culprit behind a failing build and you can even configure options such as Twitter and Calendar updates at the end of a build. There is no shortfall of notifications and events in the system.

The server also had a very pleasing interface. It’s very professional looking and has quite a few Ajax-enabled components.

This tool definitely has it all and the best part is that a trained monkey could configure it. Also, once you get your projects running in it, which doesn’t take long, you can be hands off and coding while Hudson is taking care of your developer and QA builds. You can eve setup deployments to automate your production deployments and set permissions for users to set who can and cannot do certain tasks.

There really isn’t a point if asking if Hudson supports a certain configuration because there is always a plugin to accomplish the task at hand if the out of the box configuration won’t do it. Hudson will save you time, many and make a better software product in the process. You can’t lose. What are you waiting for? Download Hudson today.


Building a project with Apache Ivy

I really love Maven, but sometimes building a Java project isn’t easy when the project and it’s ant scripts have been around for a while. Converting to Maven is not an easy task in this case, but Ivy makes this really simple…once you figure out how to use it.

Just in case you need to be sold on the benefits of using Ivy, here are some key reasons.

1. With Ivy it is no longer necessary to store jars in version control.
2. With Ivy you can upgrade a jarby simply changing the xml
3. Ivy can manage which jars are included and excluded in a war or ear file
4. Ivy can utilize any Maven repository for building

Need I go on…

Ivy is a dependency management library that integrates with Ant. It supports Ivy repositories and Maven repositories. All you need to get started is the Ivy jar in your ANT_HOME/lib, an ivy.xml and a few lines in your build.xml. Lets take a look at an ivy.xml first.

<ivy-module version="2.0"

default” />


default” name=”my-common” org=”my” rev=”2.0-SNAPSHOT” transitive=”false”>

The ivy.xml is pretty straightforward. This one contains many different examples. Ivy is very flexible. The example if for bulding and publishing a war, but you can remove all the configuration options from the dependencies if you are building a single jar.

Now we need the build.xml. This is a bit overkill, but it has all the options you’ll need. The ivy:cachepath tag allows you to build your classpath from your Ivy cache as opposed to copying jars to a local directory and building from there. You only need to call ivy:retrieve in the event that you need to copy jars into the WEB-INF/lib like in the example below. In a jar project, you won’t call retrieve at all. ivy:resolve will determine the location of all dependencies in the ivy.xml and download them to the cache if they are not already there. The publish will copy a finished product to your local ivy repository.

<project xmlns:ivy="antlib:org.apache.ivy.ant"

retrieve dependencies with ivy”>

<ivy:publish pubrevision="${version}"
resolver=”local” forcedeliver=”true”
update=”true” overwrite=”true” publishivy=”true” status=”integration” >

Again, here we see Ivy is extremely flexible. In this example, we also specify an ivysettings.xml file. I highly recommend that you create a Maven and Ivy repository in your enterprise somewhere and manage it with Nexus Dependency management server and point your ivy settings file to that Nexus server. If you choose this path, here is an example ivysettings.xml to get your started. In this example, the internal repositories are first in the chain and then public repositories follow. If you use a custom settings file, put it on a Web server somewhere so that everyone will have access to it.

Another useful trick when using Ivy is to use the Eclipse Ivy plugin to allow Eclipse to build and run using the Ivy.xml. Using the Ivy plugin isn’t simple, but it once you figure it out, you’ll wonder how you ever lived without it. You might even prefer Ivy over Maven for the enhanced flexibility it adds to an existing Ant project.