Migrating from Spring Webflow 1 to Webflow 2

...was relatively painless. At least in the very small app that I'm currently working on as a helper application for dealing with one of our partners' systems. The flow definition migration assistant that comes with Webflow 2 is a huge help. There are, however, a few things to take note of when it comes to differences between Webflow 1 and Webflow 2. They are significantly different beasts to say the least :

• 
  

  
  My configuration went from this (in Webflow 1) :
  

  
  

  
   <flow:registry id="flowRegistry">
    <flow:location path="/WEB-INF/flows/**/*-flow.xml"/>
   </flow:registry>
  
   <flow:executor id="flowExecutor" registry-ref="flowRegistry">
    <!--flow:execution-listeners>
     <flow:listener ref="webflowDebugListener"/>
    </flow:execution-listeners-->
   </flow:executor>
   
   <!--bean id="webflowDebugListener" class="org.springframework.webflow.execution.DebuggingListener"/-->
   
   <bean name="flowController" class="org.springframework.webflow.executor.mvc.FlowController">
    <property name="flowExecutor" ref="flowExecutor" />
    <property name="argumentHandler">
     <bean class="org.springframework.webflow.executor.support.RequestParameterFlowExecutorArgumentHandler" />
    </property>
   </bean>
    

  
  

  
  To this (in Webflow 2) :
  

  
  

  
   <webflow:flow-registry id="flowRegistry" flow-builder-services="flowBuilderServices">
    <webflow:flow-location-pattern value="/WEB-INF/flows/**/*-flow.xml"/>
   </webflow:flow-registry>
  
   <webflow:flow-executor id="flowExecutor" flow-registry="flowRegistry">
    <webflow:flow-execution-listeners>
     <!-- webflow:listener ref="webflowDebugListener"/ -->
     <webflow:listener ref="securityFlowExecutionListener"/>
    </webflow:flow-execution-listeners>
   </webflow:flow-executor>
   
   <bean id="securityFlowExecutionListener" class="org.springframework.webflow.security.SecurityFlowExecutionListener" />
   
   <webflow:flow-builder-services id="flowBuilderServices" view-factory-creator="viewFactoryCreator" conversion-service="webflowConversionService"/>
   
   <bean id="webflowConversionService" class="com.mypackage.modules.springframework.webflow2.ConversionServiceFactoryBean">
    <property name="editorMappings">
     <map>
      <entry key="java.util.Calendar"><idref bean="sqlDateCalendarEditor"/></entry>
     </map>
    </property>
   </bean>
  
   <bean id="viewFactoryCreator" class="org.springframework.webflow.mvc.builder.MvcViewFactoryCreator">
    <property name="viewResolvers">
     <list>
      <ref local="xmlViewResolver"/>
      <ref local="decoratedJstlViewResolver"/>
      <ref local="urlBasedViewResolver"/>
     </list>
    </property>
   </bean>
  
   <bean id="webflowDebugListener" class="org.springframework.webflow.execution.DebuggingListener"/>
   
   <bean name="flowController" class="org.springframework.webflow.mvc.servlet.FlowController">
    <property name="flowExecutor" ref="flowExecutor" />
    <property name="flowUrlHandler">
     <bean class="org.springframework.webflow.context.servlet.DefaultFlowUrlHandler" />
    </property>
   </bean>
    

  
  

  
  Now, you may be asking yourself, "Why would there be more configuration in Spring Webflow 2 ? Doesn't Spring generally improve on things like configuration syntax between major versions ? The answer is, of course, yes. However, there are a number of new features that come with Webflow 2 that need to be configured, hence the extra beans for configuration. Note also, that the syntax has changed. I direct your attention to the added 'flow-' prefixes on element names of the previously existing Webflow elements.
  

  
  


• 
  Webflow 2 has much better, much closer integration with Spring Security, hence the need for SecurityFlowExecutionListener listed above. I haven't had a chance to play around with the new integration between Spring Security 2 and Spring Webflow 2, but I'm quickly getting there.
  


• 
  Thanks to the built in model binding and validation that comes with Spring Webflow 2, there's much less syntax for views that simply bind to a model object on transitions. Instead of having to add in FormActions and adding action elements to the view-state you want them applied to, you can now simply specify a model name for the 'model' attribute of the view state, and Webflow 2 will automatically bind the form object for you (which leads us into our next point). Of course, the Spring developers maintained their usual style of keeping things as configurable as possible, so you can not only choose not to bind the model object for particular state transitions, but you can disable validation as well, using the new 'bind' and 'validate' attributes of Webflow 2 'transition' elements.
  


• 
  Because Webflow 2 can now do binding and validation for us right in the flow definition without having to define FormAction beans in our Spring ApplicationContext, Webflow 2 comes with its own updates to the spring-binding framework, hence the need for the 'webflowConversionService' bean in the configuration above. Now, you're probably saying to yourself right now, "Well what the fuck am I supposed to do with the custom PropertyEditors I wrote for my objects when dealing with Spring / Webflow 1 ?". Don't worry, all is not lost. There's a PropertyEditorConverter class that adapts PropertyEditor implementations to the new Webflow 2 Converter interface. You can use this to interface your editors with Webflow 2, and in fact that's what I did.
  


• 
  Webflow 1 left it up to the Spring framework to resolve and render views. Some people found this inconvenient, so Webflow 2 now allows you to have Webflow directly resolve and render views itself. However, since I'm already using the Spring framework and don't need Webflow's abstraction away from the underlaying framework, I chose to keep the Webflow 1 style of resolution and view rendering, hence the need for the 'viewFactoryCreator' bean above.
  

Once all the new configuration was done and out of the way, it was simply a matter of upgrading my existing flows to the new Webflow 2 syntax, which was almost entirely taken care of by the migrator that comes with Webflow 2. Previously, I used the 'var' element heavily to make use of beans in my Spring ApplicationContext, but the 'var' element has since had its usage completely reworked for Webflow 2, so I'm going to have to refactor a couple of my flows and change my style of design with Webflow 2.

One other feature that I'm learning about as I write this post is the Webflow 2 PersistenceContext. It's a solution for the use case where you want to be able to load objects from a database, and only allow a single user to be able to access them at once, ie you wouldn't want multiple people logging into a database and being able to access data on a particular user at the same time and potentially overwrite each others' changes. I'll post more about that later.

Migrating from Acegi Security to Spring Security 2

In an effort to keep our applications current, I've been looking at upgrading from Acegi Security to Spring Security 2 in one of our smaller applications as a test, to see how well it'd go over for our larger applications. So far, the tests are pretty positive. The main advantage to the migration that I can see is improved Web Service security (which I'll definitely be needing), as well as a considerably simplified configuration syntax. The following is a small migration guide :

0. If you haven't already, update your project to use Spring 2.5.4 or greater. This is necessary because of changes to Spring that Spring Security (as well as other Spring subprojects) requires. If you're using Maven 2, this is dead easy, you need only update the <version> elements of the appropriate dependencies.

1. Change all package references starting with 'org.acegisecurity' to 'org.springframework.security' in your code. If you've architected your system right, this should mean very few changes.

2. In your POM, remove all mention of Acegi security and replace it with the following :

<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-core-tiger</artifactId>
    <version>${spring.security.version}</version>

    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
        </exclusion>

        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-support</artifactId>
        </exclusion>
    </exclusions>

</dependency>
...
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-taglibs</artifactId>
    <version>${spring.security.version}</version>

    <exclusions>
        <exclusion>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
        </exclusion>

    </exclusions>
</dependency>

The exclusions are necessary to prevent Spring 2.0.x dependencies from being unnecessarily pulled in.

3. Go through your JSPs and remove all xmlns:authz="..." declarations and replace them with :

    xmlns:security="http://www.springframework.org/security/tags"

4. Go through your applicationContext*.xml files and replace any constants you may have referring to Acegi security with their proper Spring Security 2 counterparts. This means replacing the package prefixes 'org.acegisecurity' with 'org.springframework.security' and in some cases replacing ACEGI with SPRING_SECURITY in some static constant names.

This migration guide was based on (and expanded from) the one provided by Matt Raible. If you get the time, I recommend you check out his site, he has a lot of good wisdom and examples to share.

On Hibernate UserTypes

Hibernate UserTypes are a great way for persisting complex classes which may require more than one column in a table in order to be properly represented in a database. Many people have used them successfully in order to be able to simplify storage of complex objects and thus simplify their applications at the same time. One simpler use case of them was to create Enum types before support for Java 5+ enums came along.
Now, you'd think that once you've got Java 5 support with Hibernate, you'd never have to use such a simple use case again because you've got the Enums themselves, along with the @Enumerated annotation you can place on fields and properties, right ? Wrong. I've recently started migrating my projects to Spring Security from Acegi Security, and I've found that in the process, they've made the GrantedAuthority interface extend Comparable. This conflicts with the fact that Java 5+ Enums already implemented the Comparable interface with a generic parameter, and as such your code won't compile if you have an Enum that also implements GrantedAuthority, such as the following :

public enum Role implements GrantedAuthority, ConfigAttribute
{
 ROLE_ADMINISTRATOR;

 public String getAuthority() {
  return name();
 }

 public String getAttribute() {
  return name();
 }

 public String getMessageKey() {
  return "enum.Role.".concat(name());
 }
}

In order to remedy the conflict, I've had to convert my nice, pretty, simple Enum into a class, and simulate Java 5+'s enum behaviour, like so :

public final class Role implements GrantedAuthority, ConfigAttribute, Serializable, Cloneable {

 private static final long serialVersionUID = 1L;

 public static final Role ROLE_ADMINISTRATOR = new Role(0, "ROLE_ADMINISTRATOR");

 private static final Role[] VALUES = new Role[] {
  ROLE_ADMINISTRATOR
 };
 
 private static final Map NAME_MAPPINGS = new HashMap();
 
 static {
  Arrays.sort(VALUES, new Comparator() {
   public int compare(Role o1, Role o2) { 
    return o1.ordinal - o2.ordinal;
   }
  });
  
  for (Role r : VALUES) {
   NAME_MAPPINGS.put (r.getName(), r);
  }
 }
 
 private int ordinal;
 private String name;

 //Constructors

 /*
  * DO NOT EVER USE THIS! It exists only for serialization purposes.
  */
 public Role() {
  super();
 }
 
 private Role(Role r) {
  this(r.ordinal, r.name);
 }

 private Role(int ordinal, String name) {
  super();
  this.ordinal = ordinal;
  this.name = name;
 }

 //Behaviour Methods

 public int compareTo(Object o) {

  if (o == null || o.getClass() != Role.class) {
   throw new IllegalArgumentException(
     "Comparison object may not be null, and must be a Role");
  }

  return this.ordinal - ((Role) o).ordinal;
 }
 
 public String getAuthority() {
  return getName();
 }

 public String getAttribute() {
  return getName();
 }

 //Pseudo-properties

 public String getMessageKey() {
  return "enum.Role.".concat(getName());
 }
 
 //Property Accessors

 public final int getOrdinal() {
  return this.ordinal;
 }

 public final String getName() {
  return this.name;
 }

 //Helper Methods
 
 public static final int hashCode(Role r) {
  return r == null ? 0 : r.hashCode();
 }
 
 public static final boolean equals(Role x, Role y) {
  return x == null ? (y == null) : x.equals(y);
 }
 
 public static final Role clone(Role r) {
  return r == null ? null : r.clone();
 }
 
 public static final Role[] values() {
  return VALUES;
 }
 
 public static final Role valueOf(String s) throws IllegalArgumentException {
  
  String key = defaultString(s).toUpperCase();
  
  if (NAME_MAPPINGS.containsKey(key)) {
   return NAME_MAPPINGS.get(key);
  } else {
   throw new IllegalArgumentException("No role by the name ["+s+"] exists");
  }
 }
 
 //Object Overrides
 
 @Override
 public String toString() {
  return new StringBuffer().append(this.name)
   .append("(").append(this.ordinal).append(")")
   .toString();
 }

 @Override
 public Role clone() {
  return new Role(this);
 }

 @Override
 public int hashCode() {
  final int prime = 31;
  int result = 1;
  result = prime * result + ((this.name == null) ? 0 : this.name.hashCode());
  result = prime * result + this.ordinal;
  return result;
 }

 @Override
 public boolean equals(Object obj) {
  if (this == obj)
   return true;
  if (obj == null)
   return false;
  if (getClass() != obj.getClass())
   return false;
  final Role other = (Role) obj;
  if (this.name == null) {
   if (other.name != null)
    return false;
  } else if (!this.name.equals(other.name))
   return false;
  if (this.ordinal != other.ordinal)
   return false;
  return true;
 }

}

Once this was done, I created a Hibernate UserType implementation for Role, so that Hibernate could persist Roles as Integers, just as was already being done for the Enum version of Role:

public class RoleUserType implements UserType {

 private static final int[] SQL_TYPES = new int[] { Types.INTEGER };
 
 public static final String HIBERNATE_TYPE_NAME = "RoleUserType";

 public Object deepCopy(Object value) throws HibernateException {
  return value;
 }

 public Object assemble(Serializable cached, Object owner) throws HibernateException {
  return (Role)cached;
 }

 public Serializable disassemble(Object value) throws HibernateException {
  return (Role)value;
 }

 public boolean equals(Object x, Object y) throws HibernateException {
  return Role.equals((Role)x, (Role)y);
 }

 public int hashCode(Object x) throws HibernateException {
  return Role.hashCode((Role)x);
 }

 public boolean isMutable() {
  return false;
 }

 public Object nullSafeGet(ResultSet resultSet, String[] names, Object owner) throws HibernateException, SQLException {
  int roleOrdinal = resultSet.getInt(names[0]);
  
  return resultSet.wasNull() ? null : Role.values()[roleOrdinal]; 
 }

 public void nullSafeSet(PreparedStatement statement, Object value, int index)
   throws HibernateException, SQLException {
  if (value == null) {
   statement.setNull(index, Types.INTEGER);
  } else {
   statement.setInt(index, ((Role)value).getOrdinal());
  }
 }

 public Object replace(Object original, Object target, Object owner) throws HibernateException {
  return original;
 }

 @SuppressWarnings("unchecked")
 public Class returnedClass() {
  return Role.class;
 }

 public int[] sqlTypes() {
  return SQL_TYPES;
 }

}

Once the Hibernate UserType implementation was written, it was just a matter of adding my model package to Hibernate's list of annotated packages (using Java 5 after all) :

@TypeDef(name = RoleUserType.HIBERNATE_TYPE_NAME, typeClass = RoleUserType.class)
package com.mypackage.model;

import org.hibernate.annotations.TypeDef;
import eu.alenislimited.acshelper.support.hibernate.RoleUserType;

After defining the Hibernate UserType type, it was then just a matter of going around to all my fields that used Role, and replacing ...

@Enumerated(EnumType.ORDINAL)

... with ...

@Type(type = RoleUserType.HIBERNATE_TYPE_NAME)

Fortunately, doing the conversion was just extra work, and didn't require any special changes to any of my Spring configuration, or even my Hibernate configuration (beyond adding the @TypeDef to my model package and adding it to my Hibernate SessionFactory's list of annotatedPackages).

A first time gem creator's addendum

I recently started researching how to create Ruby Gems because I was working on on a Ruby application that is a reference application for accessing our production system at work, and I wanted to make the specific access code for our production system a Gem in Ruby so that I could just hand it off to future clients who want to integrate with Ruby. Further to that end, I read about the Newgem gem, and so I decided to use it, since it had recently hit 1.0.1. You can read the documentation there, so I won't repeat it here, but there's a couple of things you should do, prior to following their instructions.

1. Set a 'HOME' environment variable if you're using Windows (as I am)


2. gem install cucumber newgem


3. rake config_hoe

The first step is to install newgem, but to also ensure that cucumber is installed as well because it's an unlisted dependency. The second step is to ensure that there's a basic .hoerc file created in your home directory that's ready to go whenever you want to run any tasks on your gem while testing / packaging it. I'm guessing it's automatically created in Linux, but I had to manually set the 'HOME' environment variable and run the configuration task myself in order to have the proper configuration file generated for me to run the tasks for creating and testing my gem.