TCJUG = Spring 3.0

I went to the May Java Users Group lecture last week.  I came away with the feeling that the Spring Framework was about the coolest thing in the world.  The presentation, however, was mostly about Spring 2.5, with a few new Spring 3.0 things.

The highly anticipated 3.0 feature is the REST support in Spring.  While browsers only implement GET and POST, the new REST wiring in Spring allows you to do such things as tell a form to submit using the idempotent PUT method.  It also allows you to vary your request mapping based on the HTTP method.  For example, every web developer in history has built a form that must both be filled with default data (i.e.  a GET request) and submitted (i.e. a POST request).  The flow ends up at the same URL, but now you can branch behavior (either update the database or select from the database) based on the HTTP method used to reach the form page.

The powerful annotations of 2.5 are enhanced in 3.0, allowing less reliance on XML. The wiring is now defined in the classes themselves. This has the disadvantage of requiring a compile when you change the code, whereas XML did not, but it has the advantage of reducing the number of places you need to change things. It also, as the creator of Spring pointed out in a podcast[1], changes your definition from where and when to just when because the where is implicitly defined by where in the source code you place your annotation.

@requestParam in method signature eliminates the need to pull values out of Request Object.

• Previously you may have done:   method(HttpServletRequest request, HttpServletResponse response){ String theName= request.getParameter(“theName”);
• Now, you can do:  method(@RequestParam(“theName”) String theName);

paths for request mapping can have wildcard/variables as in artist/{artistId}/album/{albumId}/

Binding complex types to a form. Instead of just text in a form field, you can inform a simple html text element that it is, in fact, a horse, or a currency or a date, or even part of a larger object like a book order.

flexible method signatures. This is a 2.5 feature. For example, older versions required a return type, here you can go ahead and return void instead of null if your method does not need to return anything.

ETag caching.  An Etag is a header in the response object.  It looks like this:

ETag: 333565bb8c284d8afad71192f209435d

That long string represents a message digest of the content, generated by the server, and serving as a unique identifier. When the browser requests the page again, it sends along this long string and if it matches what the server has stored, the server returns a 304 message, “the resource has not changed”.  This article shows how an implementation might be hand-coded in Spring. 3.0M1 has a filter built in called ShallowEtagHeaderFilter that does what the article suggests.  By shallow they mean, “the generated jsp is the same and even though we worked to generate it, we won’t bother sending it over the wire”.  By deep, they mean that somehow, the underlying data structure can be checked for changes, and the jsp won’t even be generated.  A deep Etag filter is in the “maybe” stage.

Paths in Spring MVC can be altered to, for example, put .json at the end to return json output.

Right now, to validate a form, spring users generally pass the request through a class that implements Validator, which is fine, but once you are high on annotations, you will want to use annotations for validation as well.  This is not yet implemented in Spring 3.0 but it will soon follow <a href=”http://jcp.org/en/jsr/detail?id=303″>JSR 303 Bean Validation</a> recommendations.

See also:

1. Java Posse podcast interview with Spring founder Rod Johnson covers some of the same things.
2. Google Guice and SpringSource have partnered to standardize on annotations
3. summary of spring 2.5 features.