A couple of months ago I wrote a step 1 on migrating a classis J(2)EE application to a spring based application. Recently I had some time again on my hands and after studying the application and also after some discussions I had I decided to structure the project a little different.

“External” applications

The Adventure Builder applications uses 4 other applications to deliver its services. However in a normal real situation those 4 applications are outside of our control. We cannot change them nor redeploy them. So I decided to just include the ear files for those 4 projects instead of rebuilding them each time.

Generated stubs/skeletons

The application makes use of generated java and xml files. Also in a real situation you should generate those once and after that reuse. You should only (re)generate those files if the external interface changes (best would be to not generate at all). I decided to use the generated java files and xml files and include them in the project. They can be found in the src/generated directory.

Deployment

Deployment is now maven based, maven can start and create a glassfish domain for you. It will create all jms/jdbc/mail resources and deploy the 4 external applications. After that setup you can choose to start glassfish with the normal startServ command or reuse maven to start it. Simply run the setup.bat/setup.sh file from the setup directory. To deploy our own 2 applications simply go to the apps directory and type mvn glassfish:deploy.

Testing

The initial project as is has some test classes available so that we can make sure that the application still behaves as it should behave after we are going to change it to use Spring and Hibernate.

Hopefully Step 2 will follow shortly and that we can have a look at the different steps and easier code.

A few weeks ago I was contacted by packt publishing to review one of their books. They asked me if I wanted to review Spring Web Flow 2 Web Development (sample chapter).

In short the book consists of 254 pages in all those pages they try to explain Spring Web Flow, Maven, Ant+Ivy, Spring Security and some basics (and also not all basics) about the Spring Framework it self. Ofcourse not to mention all the normal stuff like title pages and indexes. All the explaining of the added frameworks takes away from the actual goal and that is to cover and explain Spring Web Flow. I also found that there is no real layering/build up in the book, they directly start with FlowExecutionListeners even before they covered the basics. Another draw back is the samples used, they don’t really use one sample (application) but different snippets which make it harded for a new Spring Web Flow user to get an overall feel. So the short verdict I wouldn’t say the book is bad but it could be a lot better, most of the information to be found in the book but it can be quite a search at times. If you are a Spring Web Flow beginner I would try to find other books covering the basics of Spring Web Flow.

After the short version here is the somewhat longer version a chapter by chapter brief coverage of the book. The opinions here are my own and are quite influenced by the fact that I have written some initial code for Spring Web Flow and Spring Security integration and that I was part of the team that wrote the training on Spring Web Flow.

The book starts with a short and quick introduction to the 3 pillars/corners stones and briefly discusses the changes between Spring Web Flow 1 and 2. The chapter is a bit confusing due to the fact that they use flow and conversation interchangeably. There are some small parts that could be improved here but all in all not a bad chapter.

The second chapter discusses the setup to run the examples which come with the book. They explain it using maven, ant+ivy and how to do it with various IDEs. They also give a ‘basic’ sample of a flow, however they right away start with FlowExecutionListeners, all the different states that there are and try to explain it. However the explanation is to brief (allthough everything is covered in the book). I would have sticked with 1 build solution and 1 IDE. That would also make it easier to read and understand, now with each sample the book covers both maven and ant+ivy. Also showing a sample with everything included and calling it ‘a basic sample’ isn’t the best thing to do. The sample flow also uses depracted states (action-state is basically deprecated) and doesn’t use/follow best practices. Overall everything is in the chapter but it is either to much or to little.

The third chapter explains the basics of Spring Web Flow. The chapter start with the explanation of how xml is composed and after that starts with explaining the persistence context and FlowExecutionListeners. Both not really ‘basics of Spring WebFlow’. Halfway the chapter they start explaining the basics, the different states, the different scopes, how the variable resolution mechanism works etc. Basically they try to explain everything about Spring Web Flow with jsp in 1 chapter and they don’t really explain it in the right order. Some parts could have been in more detail others are in to much detail. Also parts that would be interesting, like how to influence binding and how to do type conversion, aren’t covered. In my opinion this chapter lacks what it needs.

The fourth chapter is about integration JSF with Spring Web Flow. They again briefly explain how to do it and they try to explain how to integrate 2 different JSF frameworks with Spring Web Flow. However the latter removes us from the real objective which is the Spring Faces module and how to use it. Some of the code and things they explain aren’t really true (like the custom ResourceServlet you would need!), next to that they are also trying to explain how the Spring Namespace support works which doesn’t really apply nor does it add something here.

The fifth chapter covers AJAX. They brush on element decoration and progressive enhancement, however they don’t really explain why one should use it. The book covers the configuration and usage of Spring Javascript and next delves into partial page rendering with the use of Apache Tiles. The beginning of the chapter is pretty good however they end with explaining the whole Spring Web Flow configuration xsd. This is better left to the reference guide or in an appendix in the book. The chapter starts off good however seems/feels likes to be rushed to an end with explaining the xsd which also feels oddly out of place here.

Chapter six covers testing and the testing of subflows. One of the best chapters in the book, it covers testing pretty good and also touches on the subject of mocking your objects and perform tests. Confusing in this chapter arises due to the use of 2 different versions of the testing framework, stick with 1 version I would say.

Chapter seven dives into Spring Security and using that to secure your flows. Again they try to explain Spring Security and the mix with Spring Web Flow in 1 chapter, this doesn’t really work. They explain to little and in places don’t do justice to what Spring Security can do. Not all to bad but it again coud have been better then what it is.

A lot of stuff gets covered in this book but it doesn’t read pretty easy. The beginning of the book directly covers FlowExecutionListeners even before explaining the real basics of Spring Web Flow. If you need something it probably is in there but not in the most likely location. They also use different samples through out the book, if they would have used just one sample application it would have been easier to understand and to give everything a place. The code samples are at times also confusing and use different styles (jsp 2 and jsp 1 syntax, use of deprecated code, incomplete/incorrect code samples etc) and sometimes use different versions of the same framework. Things that would have been good to explain aren’t explained (binding, object conversion).

All of this leaves me no choice then to not recommend this book especially if you are a Spring Web Flow beginner. Try to find another book there are probably better ones out there.

A few months ago SpringSource released a white paper describing the migration from J2EE to a Spring framework based application. Even before they wrote that white paper I already had the idea of writing something about how to migrate from J2EE to a Spring based application. However Colin Sampaleanu (at al.) beat me to writing the white paper .

However I also had the idea of providing some practical information like a sample. The white paper gives some thought on what to do and where but it doesn’t give a clear sample. So I started writing a possible migration path (multi step sample) from a J2EE application to a Spring based application.

The code is available in a repository hosted on googlecode. Please feel free to checkout the code (for each step there will be a branch/tag). If you have suggestions/issues with the code also please feel free to register an issue or supply a patch.

For this sampe I took the SUN blueprint application (I focused on J2EE 1.4 because that is widely used and adopted and there is still a lot of ‘legacy’ out there build with the 1.4 spec) called the ‘Adventure Builder‘. To make it a easier to build and migrate I started migrating the application to a maven build (instead of the asant build).

In the next few post I’ll explain the migration strategy, the different steps and here and there some best practices which later on will ease the migration path. I’m not going to migrate all the applications (the Adventure Builder sample consists of several applications), I’m focussing on the ‘Order Processing Module’ and later on the ‘Consumer Website’ application all of this without changing the other applications (or with minor changes).

Development for this project is done in the SpringSource Toolsuite. Deployment is done in the ‘Glassfish‘ application server. To make it easier to build I first migrated the blueprint application to a maven based build.

To build, install and deploy the application follow the following steps (after checking out the code from svn).

1. goto the parent project inside the springstore application
2. mvn clean -Dskip.resources=true (skip.resources disables deletion of the jms/jdbc resources in glassfish)
3. mvn glassfish:start-domain (start glassfish)
4. mvn install (will build the ear files, and generate the jms/jdbc resources and fills the test database)
5. mvn glassfish:deploy

Afterwards the applications is available on your localhost just play around with the application and have a look at the code. (If you want you can compare it to the original Adventure Builder application it should be more or less the same.

If you want to undeploy the applications simply type glassfish:undeploy

I still have a few issues with the maven based build, so if someone can help/advice on that please let me know.

It seems quite hard to configure a JNDI Resource in Tomcat. Especially when it comes to configuring XA capable resources. The key lies in understanding how Resources work/need to be configured.

A Resource has a few properties which are used by Tomcat, those are the auth, name, description, scope and type, from those name and type are required. Type is the actual type (fully qualified classname) it needs to create and the name is the jndi name relative to java:comp/env.

All the other properties specified on the Resource element are either used by the factory or the type created by the factory. So if you specify a property named ‘username’ in your Resource then there must be a get/set pair for that property on the type (i.e. setUsername/getUsername).

If we look at the mysql sample from the Tomcat documentation.

<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"
          maxActive="100" maxIdle="30" maxWait="10000"
          username="javauser" password="javadude"
          driverClassName="com.mysql.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/javatest?autoReconnect=true"/>

We register a javax.sql.DataSource with the name jdbc/TestDB and the authentication is done by the Container. Now if we look further we see a few properties.

• maxActive
• maxIdle
• maxWait
• username
• password
• driverClassName
• url

If we don’t specify an explicit type and/or a factory Tomcat uses its default implementation which is Apache Commons DBCP. For the default javax.sql.DataSource it uses also the default/basic implementation of that library, it uses BasicDataSource. If you study the javadoc of that class you will see a getter/setter pair for each of the properties named above.

Now lets put into practice all what we have learned here and try to configure a Mysql XA Capable datasource. We first need to specify the specific factory to use else the default factory will be used. The factory to use is the MysqlDataSourceFactory

Next we need to specify the type the factory needs to instantiate, we want a MySQL XA DataSource and thus we need to instantiate com.mysql.jdbc.jdbc2.optional.MysqlXADataSource. A list of the configurable properties can be found in the MySQL reference documentation.

<Resource name="jdbc/TestDB" auth="Container"
          type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"
          factory="com.mysql.jdbc.jdbc2.optional.MysqlDataSourceFactory"
          user="javauser" password="javadude" explicitUrl="true"
          url="jdbc:mysql://localhost:3306/javatest?autoReconnect=true"/>

And there we have it a configured XA Capable Mysql datasource. I think the MysqlDataSourceFactory can be improved a lot the same goes for the javadocs for the connector. However with a look at the sourcecode and a good understanding on how JNDI Resources can be configured in Tomcat it is quite easy to figure out how Resources can be configured.

Well that is the title of the presentation I just gave at the NL-JUG 2007 conference. The presentation was about the Spring Web Flow solution we created to secure flows. The presentation can be found and the conference website. The code is available in the JIRA under issue SWF-93 but for your convenience also available for download (press the link on the bottom of this post).

The presentation went well, there were some nice questions and a little bit of discussion. So my conclusion was that it was a nice presentation. I will blog about using this security solutions shortly. However for now I have a conference to attend.

WebFlow Security

This week alone I answered the question about date formatting and how to bind Strings to Objects multiple times. If I would get an euro/dollar for everytime I gave the same answer. So I figured maybe it is time to create simple example to show how it is done in Spring. (The sources used are included in the propertyeditors.zip attached to this post, rename to .war to deploy it in tomcat or jetty (tested in Jetty 6.0.2))

For this project we will only use a WebApplicationContext so the only thing we need to do is configure the Spring DispatcherServlet.

Step-By-Step
sbs
org.springframework.web.servlet.DispatcherServlet
1

sbs
*.do

index.jsp

As you see we mapped all the *.do to the dispatcher servlet. Problem with the servlet spec is that the welcome page has to be a physical file. So the index.jsp only does a redirect to index.do. The Servlet is named sbs. As with the Spring convention we then need to create sbs-servlet.xml to get the context loaded. For this example I use the default BeanNameUrlHandlerMapping, which resolve an URI to a Controller.

We also need something to resolve our views (a ViewResolver) so I configured an InternalResourceViewResolver, which looks up jsp in the WEB-INF/jsp directory.

[sourcode language='xml']
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd”>

[/code]Well that is it, configuration wise. We have a controller, with a form and a validator, we have 2 views (entry and success).

The controller isn't that big of a deal, it extends simpleformcontroller and only implements the initBinder method. For binding to other objects then Strings or primitives we need a PropertyEditor. Luckily for us Spring comes shipped with some PropertyEditors. For this example we will use the CustomDatePropertyEditor. The PropertyEditor will convert a String to a Date and vice-versa.

public class DateEntryController extends SimpleFormController {
  protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) throws Exception {
    SimpleDateFormat dateFormat = new SimpleDateFormat("dd-MM-yyyy");
    CustomDateEditor editor = new CustomDateEditor(dateFormat, true);
    binder.registerCustomEditor(Date.class, editor);
  }
}

The initBinder method as mentioned here, registers a CustomDateEditor which takes a text in the format (dd-MM-yyyy) and transforms that into a valid date.

the line 'binder.registerCustomEditor(Date.class, editor);' tells the binder to register this propertyeditor for all the Date properties on the command object. If there is a need for multiple property editors for the same type you can also specify the name of the property on the command object.

The Validator is a simple one (just to generate some errors and show that valid dates are translated back into strings).

public class DateEntryValidator implements Validator {

  public boolean supports(Class clazz) {
    return DateEntryFormObject.class.isAssignableFrom(clazz);
  }

  public void validate(Object target, Errors errors) {
    DateEntryFormObject commandObject = (DateEntryFormObject) target;
    Date startDate = commandObject.getStartDate();
    Date endDate = commandObject.getEndDate();

    if (startDate == null) {
      errors.rejectValue("startDate", "required", "Starting Date is required.");
    }

    if (startDate != null && endDate != null && endDate.before(startDate)) {
      errors.rejectValue("endDate", "notbefore.startdate", "End date cannot be before start date.");
    }
  }
}

Well that's all there is. The only remaining things are the 2 jsps and the command object.

public class DateEntryFormObject implements Serializable {

  private Date startDate;
  private Date endDate;

  public Date getEndDate() {
    return endDate;
  }

  public void setEndDate(Date endDate) {
    this.endDate = endDate;
  }

  public Date getStartDate() {
    return startDate;
  }

  public void setStartDate(Date startDate) {
    this.startDate = startDate;
  }
}

entry.jsp

<%@taglib prefix="form" uri="http://www.springframework.org/tags/form">
<table>
  <tr>
    <td colspan="3">Enter dates in format (dd-MM-yyyy)</td>
  </tr>
  <tr>
    <td>Start Date:</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>End Date:</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
  <td colspan="3"><input value="Submit dates" name="enter" type="submit" /></td>
  </tr>
</table>

<%@taglib prefix="form" uri="http://www.springframework.org/tags/form">
<table>
  <tr>
    <td colspan="2"><h2>Dates entered</h2></td>
  </tr>
  <tr>
    <td>Start Date:</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>End Date:</td>
    <td>&nbsp;</td>
  </tr>
</table>

There is just one important thing to remember PropertyEditors work only for the command object, not for reference data, or objects stored somewhere else. For those to format correctly you will need the good ol' fmt tags.

In one of my recent projects we came a cross an application model which had 1 codebase but for every client they had (around 40) they deployed one application. Sometimes they had to redeploy several times because they had memory and performance issues. We soon realized that we needed to do something about this way of deploying. The only two things which where different per client where the database connection and the front-end.

Front-end
Well the front-end is simple enough there are enough templating engines around which you can use. We decided on using sitemesh this in combination with JSTL gave us all the power we needed.

Database connection
But what about the database connections. We had 40 of them configured in our tomcat context file. We figured we needed something like the HotSwappableTargetSource. The challenge was how do we decide for which client we need to process something. The application has urls like http://www.ourcomp.com/client1 and http://www.ourcomp.com/client2 etc. We created a filter which extracted the client1 part from the URL and put that in a ContextHolder (which is a ThreadLocal).

public abstract class ContextHolder {

  private static final ThreadLocal holder = new ThreadLocal();

  public static void setContext(String context) {
    LoggerFactory.getLogger(ContextHolder.class).debug("context set '{}'", context);
    holder.set(context);
  }

  public static String getContext() {
    return (String) holder.get();
  }
}

Now we had the context to use in a property we could retrieve anywhere. So next we took the idea of the HotSwappableTargetSource and adapted it for our situation. We created a ContextSwappableTargetSource, we need to create it with the targetClass is provides (in our case a javax.sql.DataSource) and with a map of DataSources to use. The keys in the map correspond to the context (or clientnames) used in the url.

/**
* TargetSource which returns the correct target based on the current context set in the {@link biz.deinum.springframework.core.ContextHolder}.
* If no context is found a {@link TargetLookupFailureException} is thrown or the <code>defaultTarget</code> is returned
* , depending on the setting of the alwaysReturnTarget property (default is false);
*
* @author M. Deinum
* @version 1.0
* @see ContextHolder
* @see TargetSource
*/
public class ContextSwappableTargetSource implements TargetSource, InitializingBean {
  private final Logger logger = LoggerFactory.getLogger(ContextSwappableTargetSource.class);
  private Map targets = Collections.synchronizedMap(new HashMap());
  private Class targetClass;
  private boolean alwaysReturnTarget = false;
  private Object defaultTarget;

  /**
  * Constructor for the {@link ContextSwappableTargetSource} class. It takes a
  * Class as a parameter.
  *
  * @param targetClass The Class which this TargetSource represents.
  */
  public ContextSwappableTargetSource(Class targetClass) {
    super();
    this.targetClass=targetClass;
  }

  /**
  * Locate and return the sessionfactory for the current context.
  *
  * First we lookup the context name from the {@link ContextHolder}
  * this context name is used to lookup the desired target. When none
  * is found we return the default target.
  *
  * If the targetClass is of a invalid type we throw a {@link BeanNotOfRequiredTypeException}
  *
  * @see ContextHolder
  */
  public Object getTarget() throws Exception {
    // Determine the current context name from theclass that holds the
    // context name for the current thread.
    String contextName = ContextHolder.getContext();
    logger.debug("Current context: '{}'", contextName);

    Object target = targets.get(contextName);
    if (target == null && alwaysReturnTarget) {
      logger.debug("Return default target for context '{}'", contextName);
      target = defaultTarget;
    } else if (target == null && !alwaysReturnTarget){
      logger.error("Cannot locate a target of type '{}' for context '{}'", targetClass.getName(), contextName);
      throw new TargetLookupFailureException("Cannot locate a target for context '"+contextName+"'");
    }

    if (!targetClass.isAssignableFrom(target.getClass())) {
      throw new TargetLookupFailureException("The target for '"+contextName+"' is not of the required type." + "Expected '"+targetClass.getName()+"' and got '"+target.getClass().getName()+"'");
    }
    return target;

  }

  public final Class getTargetClass() {
    return targetClass;
  }

  public final boolean isStatic() {
    return false;
  }

  public void releaseTarget(Object arg0) throws Exception {}

  public final void afterPropertiesSet() throws Exception {
    Assert.notNull(targetClass, "TargetClass property must be set!");

    if (alwaysReturnTarget && defaultTarget == null) {
      throw new IllegalStateException("The defaultTarget property is null, while alwaysReturnTarget is set to true. " + "When alwaysReturnTarget is set to true a defaultTarget must be set!");
    }
  }

  public final void setAlwaysReturnTarget(final boolean alwaysReturnTarget) {
    this.alwaysReturnTarget=alwaysReturnTarget;
  }

  public final void setDefaultTarget(final Object defaultTarget) {
    this.defaultTarget=defaultTarget;
  }

  public final void setTargets(final Map targets) {
    this.targets.clear();
    this.targets.putAll(targets);
  }
}

All the classes are in place, now we only needed to wire things up in our application context and we should be good to go. First we configure the datasources.

Next we need to setup the ContextSwappableTargetSource, the key in the map is the value which is going to be set in the ContextHolder. In a WebApplication this value could be set by a ServletFilter on each request. The TargetSource is wrapped in a ProxyFactoryBean so a Proxy will be created for the ContextSwappableTargetSource.

And that is it. Now inject the datasourceTargetSource into a JdbcTemplates datasource property and you are good to go.

At every request the context is set in the ContextHolder. Then at every action on the JdbcTemplate the getTarget method on the ContextSwappableTargetSource is called returning the real and correct datasource instance for that request.

In this example we used it to dynamically replace DataSource instances but this can work with in theory every object. We have also succesfully used it with multiple hibernate SessionFactories.

The source code (as available on posttime) can be found here. Or point yuor favorite SVN client to http://bespring.googlecode.com/svn/trunk/. I also submitted this to the Spring framework in JIRA issue SPR-3014

A while ago we started to use Spring Web Flow. We needed to convert our old WizardForms and Multi SimpleFormController screens to the Spring Web Flow ones. After converting about three jsp’s I got fed up with the hidden fields, the submit buttons with the specified name. Generating urls with a flowExecutionKey and eventId was even worse. Also after making al those typos in flowExecutionKey I decided to create a taglibrary which can write different HTML tags needed in Spring Web Flow.

So after experimenting a bit I wrote three tags:

• FlowExecutionKeyTag: Writes hidden field with the flowExecutionKey
• UrlTag: Writes a url containing the flowExecutionKey and eventId
• SubmitTag: Writes a submit button and optional a hidden flowExecutionKey field

FlowExecutionKeyTag

<swf:flowexecutionkey/>

will generate

<input type="hidden" name="_flowExecutionKey" value="<current_flowexecutionkey>">

UrlTag

<swf:url url="somelink.flow" eventId="read" paramName="someId" value="${someObject.id}">Link</swf:url></pre>

will generate

<a href="somelink.flow?_flowExectionKey=<current_flowexecutionkey>&_eventId=read&someId=123">Link</a>

SubmitTag

<swf:submit eventId="save" value="Save"/>

will generate

<input type="submit" value="Save" name="_eventId_save">

There are 2 JIRA issues concerning Web Flow Tags, I attached this code to one of them.

• SWF-87
• SWF-116

The sources can also be downloaded from here or point your favorite subversion client to the repository at http://bespring.googlecode.com/svn/.

On a job I did recently we did a lot of refactoring the old (web) application, they used an abundance of (Web) Frameworks, we reduced it to 1 (well actually 2 if you count Spring Web Flow ).

They already had a lot of Controllers and Validators build and also somewhere some custom validation logic in the desired classes. One thing I noticed is that they had a few command objects which had an emailaddress or telephone number. For each of those objects they also wrote a suitable Validator. Copying and pasting all the logic concering emailaddress validation each time, or even worse reinvented the logic.

What I decided to do is to put the logic concerning the emailaddress validation into 1 Validator. Problem is you can only have 1 Validator on a Controller of FormAction. A bit problematic, however I couldn’t imagine that we where the first ones to run into this. So off to the Spring Forum after some search we found the CompositeValidator which we copied _{Thanks to Colin Yates for this}.

public final class CompoundValidator implements Validator {

  private final Validator[] validators;

  public CompoundValidator(final Validator[] validators) {
    super();
    this.validators=validators;
  }

  /**
  * Will return true if this class is in the specified map.
  */
  public boolean supports(final Class clazz) {
    for (Validator v : validators) {
      if (v.supports(clazz)) {
        return true;
      }
    }
    return false;
  }

  /**
  * Validate the specified object using the validator registered for the object's class.
  */
  public void validate(final Object obj, final Errors errors) {
    for (Validator v: validators) {
      if (v.supports(obj.getClass())) {
        v.validate(obj, errors);
      }
    }
  }
}

Now we have the solution for registering multiple validators for a Controller of FormAction you can create a CompositeValidator which wraps other validators.

Still we had all the emailaddress validation cluttered around, another problem to solve was in each command object the field containing the emailaddress was named differently i.e. email, emailadres, emailaddress etc. So we need to design something which could map classes to the field name needed. I couldn’t find something on the excellent Spring Forum or with Google so it was back to the coding board . I came up with the AbstractClassMappingValidator, this allows you to specify a Class and the desired field to check for that Class.

public abstract class AbstractClassMappingValidator implements Validator {    /** Prefix Strings which are added to the field names */

  protected static final String REQUIRED = "required";
  protected static final String INVALID = "invalid";

  private Map mappings = new HashMap();

  protected boolean allowEmpty = false;

  public final boolean supports(Class clazz) {
    for (Class targetClazz: mappings.keySet()) {
      if (ClassUtils.isAssignable(targetClazz, clazz)) {
        return true;
      }
    }
    return false;
  }

  /**
   * Gets the fieldname from the configured map.
   * @param target
   * @return
   */
  protected final String getFieldName(Object target) {
    for (Class targetClazz: mappings.keySet()) {
      if (ClassUtils.isAssignable(targetClazz, target.getClass())) {
        return mappings.get(targetClazz);
      }
    }
    throw new IllegalStateException("Cannot find fieldname for class " + target.getClass().getName() + ". Class is not compatible with declared types. ["+mappings+"]");
  }

  public final void setMappings(final Map mappings) {
    this.mappings = mappings;
  }

  public final void setAllowEmpty(final boolean allowEmpty) {
    this.allowEmpty = allowEmpty;
  }
}

You can configure this validator by setting its mappings property. If we have two objects(BusinessObjectOne & BusinessObjectTwo) with the fields email and emailaddress we can use the following snippet to configure the validator.

<bean id="id" class="SomeClassExtendingAbstractClassMappingValidator">
  <property name="mappings">
    <map key-type="java.lang.Class" value-type="java.lang.String">
      <entry key="com.mycompany.objects.BusinessObjectOne" value="email"/>
      <entry key="com.mycompany.objects.BusinessObjectTwo" value="emailAddressNew"/>
      <entry key="com.mycompany.objects.BusinessObjectThree" value="emailAddress"/>
    </map>
  </property>
</bean>

Now we have a CompositeValidator, we can map classes to fields to validate but we still need to check the emailaddresses against a defined regular expression. So we created a RegExpValidator it takes a regular expression and matches the value of the field against this regexp. If a field is required can also be configured.

/**
 * Validator which matches a value against a defined regular expression.
 *
 * First it checks if a given value is not empty, if empty values are allowed
 * this can be switched off. Next the value (if not empty) is checked against
 * the configured regular expression. If it doesn't match the value is rejected.
 *
 * When empty values aren't allowed and the string is empty the errorcode is
 * generated as <strong>required.fieldname</strong>. If the format is invalid the errorcode
 * is generated as <strong>invalid.fieldname</strong>.
 *
 * @author Marten Deinum
 *
 */

public final class RegExpValidator extends AbstractClassMappingValidator {    private String              regexp     = null;

  public void validate(Object target, Errors errors) {
    String field = getFieldName(target);
    String value = (String) errors.getFieldValue(field);
    boolean isEmpty = !StringUtils.hasText(value);

    if (!allowEmpty &amp;&amp; isEmpty) {
      ValidationUtils.rejectIfEmptyOrWhitespace(errors, field, REQUIRED + "." + field);
    }

    if (!isEmpty) {
      if (!value.matches(regexp)) {
         errors.rejectValue(field, INVALID + "." + field, new Object[] {field, value}, "{1} is not a valid value for {0}.");
      }
    }
  }

  public void setRegExp(final String regexp) {
    this.regexp = regexp;
  }
}

Now we have all the components in place to make the magic work. First we configure the emailaddress validator. When we have done that we can setup the CompositeValidator with multiple validators and inject the configured one into a Controller or FormAction.

Feel free to comment and to use the code, if you make any improvements please let me know everything is welcome .The code can be found on code.google.com connect to the subversion repository to get the sources of the validators(projects core and validation).