Overall, I found this a really interesting talk. It was lacking in any sales pitch, nor did it have the unquestioning devotion to one particular framework that I felt some of the Java FX talks had. Instead it seemed like an unbiased look at web frameworks in general and a handful of frameworks in more detail, based on Richard’s extensive and hands on experience and SalesForce and Hyperic.

Richard started by listing some of the web frameworks that are out there today. He managed to list over 100 and there were still many missing (e.g. I couldn’t see Lift or Play listed).

Given the abundance of choices, I think it was wise to start with a broad definition of what a web framework is. His definition included something that uses MVP or MVC and provides an event model, resource management, data binding and that is ideally stateless.

He then talked about the evolution that has taken place from server side rendering to client side rendering (where you have a stateless server, with the component model living on the client side), and had a few interesting ‘Architecture Evolution’ diagrams in his slides.

Next, Richard talked about the consequences of ‘choosing poorly’, i.e. picking a framework not best suited to your project’s needs (steep learning curves, excessive boilerplate code, unable to debug templates etc). I got the feeling Richard had learned many of these the hard way. He followed with a set of criteria to help better define your web framework requirements and selection criteria to avoid such issues, including usage scenarios, environment (intranet, mobile) and team competencies. On a side note, he pointed out that using forms for posting had become old hat (and those ‘Are you sure you wish to resend’ popups are certainly annoying).

Then, on to the main event. Richard ran through 4 of the most popular web frameworks: Grails, Tapestry, Wicket and GWT. In each case he compared them using criteria such as AJAX support, friendly URLs, open source license etc. I won’t try to recreate his findings (again, see his slides), but I did come away with a higher opinion of both Tapestry (its Form builder using POJOs sounds particularly cool) and Wicket and I am definitely keen to learn more on GWT (which Salesforce.com use extensively).

In some of the follow up questions, Richard was asked about JSF, which he didn’t have very high opinion of (and he is not alone). I was however disappointed to not hear some info (merits or otherwise) on JavaFX, especially considering its high visibility at this year’s conference, but I also understand no one can know all frameworks.

Finally, he finished with an interesting thought – that one of the main scalability issues with any web framework is people i.e. the competencies and preferences of the developers on the team.

Find Richard’s slides here.

I have created several Spring MVC projects for both work and play, and am attaching my own simple version of the HelloWorld example here, based on the Spring blog example.
Find my maven ready source here.
Like my previous JSP/Servlet example, I find these templates useful for getting prototypes up and running.

In a future article I would like to discuss validation including the use of custom error messages.

Note that these notes relate to version 2.5.6 of Spring, the latest production code at time of writing, and depend heavily on the corresponding Spring reference docs.

Data Binding

Spring MVC allows the use of command objects (aka form backing objects, model attributes, domain model objects – basically the objects used to transport data between your view and your controller) using just about any type. However, the Servlet API deals with form parameters as Strings. Spring uses a technique called data binding to covert between the String representation and the real underlying type. This enables user input to be bound to the objects you use to process user input. In other words, the values entered by a user in a form can be used to set the property values on a chosen object.
As well as binding the values, Spring includes support for validation and binding result analysis.

The binding functionality is provided by Spring’s org.springframework.validation.DataBinder class.
And when converting a String to some arbitrary type, DataBinders make use of ProperEditors. PropertyEditors are not Spring specific, but rather part of the JavaBeans API.

Using PropertyEditors

Spring heavily uses the concept of PropertyEditors to effect the conversion between an Object and a String.
Spring has a number of built-in PropertyEditors to make life easy (for a complete list, see here).
If you are using a custom type that Spring is unable to convert to and from a String, you will likely receive a lovely error such as this:

org.springframework.web.bind.ServletRequestBindingException: Errors binding onto object ‘dependsOnExoticType’; nested exception is org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult: 1 errors
Field error in object ‘dependsOnExoticType’ on field ‘type’: rejected value [test]; codes [typeMismatch.dependsOnExoticType.type,typeMismatch.type,typeMismatch.example.ExoticType,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [dependsOnExoticType.type,type]; arguments []; default message [type]]; default message [Failed to convert property value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [java.lang.String] to required type [example.ExoticType] for property ‘type’: no matching editors or conversion strategy found]

The solution is to create your own custom editor.

Creating a custom property editor

A custom property editor should be of type java.beans.PropertyEditor. It tells Spring how to convert to a String and back again. As an example, see the ExoticTypeEditor in the Spring reference docs here.

The question is then how to register the custom editor.

Registering your custom editor

There are several ways to ensure you custom editor gets registered.

1) Put Editor in same package

The simplest way (by far!) is to put the Editor in the same package as the class it handles. This is because the standard JavaBeans infrastructure will automatically discover PropertyEditor classes (without you having to register them explicitly) if they are in the same package as the class they handle, and have the same name as that class, with’Editor’ appended;

However, if putting the Editor in the same package as the class it handlers is not possible (If for example, you are using a custom type from a 3rd party library and hence you don’t have access to the source code), try one of the other options below…

2) CustomEditorConfigurer

Another approach to registering a custom PropertyEditor is to use a special bean factory post-processor called CustomEditorConfigurer.
This is the approach used in the spring reference manual for the ‘ExoticType’ example. Again, see
section 5.4.2.1. Registering additional custom PropertyEditors, here.

The CustomEditorConfigurer is used to register the new PropertyEditor with the ApplicationContext, which will then be able to use it as needed.

Gotchas

i) Won’t work with BeanFactory – only ApplicationContext
The PropertyEditors defined in the ‘customEditorConfigurer’ bean will only be automatically used if you are using an ApplicationContext implementation (i.e. will not work for BeanFactory). This is discussed here.
ii) Only works for ApplicationContext created beans – not data binding beans such as form objects
This approach only works for beans created by the ApplicationContext. The PropertyEditors that are registered via CustomEditorConfigurer are NOT available for use in the data binding infrastructure (this is discussed here and here).
I think this should be made more clear in the spring framework ref docs (although, in fairness, it is covered in the CustomEditorConfigure javadocs).

So, if you are using Spring MVC and dealing with form submission, the next option may be better…

3) Explicitly register your editor in initBinder

So, a better approach, as far as form data binding is concerned, is to explicitly register your editor within initBinder() in the relevant Controller. e.g.

@Controller
@RequestMapping("/exoticView.htm")
public class TestController {

	//post and get handling methods etc...

	@InitBinder
	protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) {
		binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
	}

}

4) Use a WebBindingInitializer

If you find yourself using the above approach (registering your customer editor in initBinder) in many controllers, and you use a annotation based controller (Spring 2.5+), then you can use a WebBindingInitializer to register global property editors.

To do this, create a class that implements the WebBindingInitializer interface, for example

public class GlobalBindingInitializer implements WebBindingInitializer {

    public void initBinder(WebDataBinder binder, WebRequest request) {
        binder.registerCustomEditor(ExoticType.class, new ExoticTypeEditor());
    }

}

Then update your web application context file to contain:

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
    <property name="webBindingInitializer">
        <bean class="GlobalBindingInitializer"/>
    </property>
</bean>

I discovered this approach in a posting on StackOverflow about hidden features of Spring . It means you can register an editor once and use it anywhere. This is now my preferred way to register custom property editors.

5) Use PropertyEditorRegistrar

Another mechanism for registering property editors with the Spring container, and the final one in the Spring reference docs, is to create and use a PropertyEditorRegistrar. See section 5.4.2.1.1 here. The docs say that this is a good approach “when you need to use the same set of property editors in several different situations”. I have used this approach successfully in the past, but to be honest, I don’t quite see the benefits beyond the GlobalBindingInitializer approach above and it seems to require a few more steps. (I also saw some confusing debate on exactly what steps are mandatory here)

6) BeanInfo

There is also a BeanInfo mechanism mentioned in the Spring docs which I admit I have never tried – or fully understood.

Unfortunately, Eclipse keeps throwing up an error saying:
java.lang.IllegalArgumentException: Argument not valid: Could not get status information from view

I think I have finally found the cause. It seems ClearCase doesn’t always start up properly on my local PC. When that happens, I have found that manually starting it seems to stop the Eclipse errors. To manually start, go to
C:\Program Files\Rational\ClearCase\Service.EXE (or your lcoal install location)
And select the “Start ClearCase Service” option.

The highlights of the second day at TSSJS2009 were a couple of interesting talks from Rod Johnson (Mr Spring) and a talk on Groovy from Scott Davis (Groovy.com).

I have included links to some of my (limited) notes below, which includes links to the actual presentation slides (PDFs) where available.

Keynote: How Spring Fits into the Java Landscape – Rod Johnson

Spring for the advanced developer – Rod Johnson

The Amazing Grrovy Weight Loss Plan – Scott Davis

Some simple JavaFX script just don’t seem to work with the Eclipse plugin. For example, the following snippet:

Stage {
    title: "Nodes"
    scene: Scene {
        fill: Color.LIGHTBLUE
        width: 220
        height: 170
    }
}

Causes the following error:

incompatible types found: integer required: com.sun.javafx.runtime.location.FloatVariable

The same snippet compiled and ran straight off when I tried it before in NetBeans.

The only posting on it I could find is here. I took the advice and downgraded to JavaFX 1.0, which seems to have done the trick for now. If anyone out there has any suggestions on better solutions/fixes, I would love to hear them.

This isn’t the first time I’ve spotted some better GUI related functionality in NetBeans than in Eclipse (e.g. I briefly mentioned the NetBeans GUI Builder tool a while ago). There is no chance of me stopping using Eclipse completely, but maybe I will start using both…

All in all, I have to say that it all looked like a very neat application. It is similar to Gigaspaces, but I suspect that since it is backed by Oracle, it is better supported.

The big question is, would I actually use it in a project? The answer is, if the project required access to a large amount of data and response times, scalability, availability and reliability were all critical requirements, then it would certainly be on the list of possible components. I can think of several real-time, mission critical trading applications that I have worked on in the past where Coherence could have been a useful tool.

One question I had was whether or not Coherence could be used with Hibernate, and in particular if it could be introduced to an existing application. After all, most performance problems don’t arise until well into the development of an application; Often when too much design and coding has been done to do a fundamental redesign.

For example, I am working on a Java/Spring/Hibernate web based application with a small but rapidly growing user base. If, in the future, performance becomes an issue, could Coherence be introduced to provide all the benefits that the folks at Oracle were talking about today? Could we introduce Coherence in to the architecture without fundamentally changing the data access mechanism (which lets face it, is not really an option at any stage other than the design or very early development)?

I think the answer is yes, but with caveats. The solution lies in using Coherence as Hibernate Level 2 Cache. The caveat is that this approach does not bring the same benefits as using Coherence as the primary data source in an application, like you would if you were using Coherence as an original, founding member of your architecture.

However, as the Oracle docs say, Hibernate is ‘the optimal choice for accessing data held in a relational database where performance is not the dominant factor’. So I guess if performace is likely to be an issue, it is best to think about it as early as possible, i.e. before picking the database technologies…

It does all this by overriding some of the Sun classes, in packages such as java.io and java.lang, with more preformant versions.

All very neat and I would really like to start using it – but a Mac version isn’t available. Eerrgh. Guess I’ll be sticking with Sun’s implementation.