Everybody’s talking about REST and RESTful web applications, so it doesn’t come as a surprise that there would be some kind of support for this architecture style in Spring sooner or later. Today at the SpringOne in Antwerp, Arjen gave a presentation on that topic and actually revealed what the announced "full-scale" REST support will look like. So here’s the details for those of you who haven’t had the opportunity to be here in Antwerp:

REST support will be based on Spring MVC instead of Spring WS
Those of you who have already had a look at the Spring MVC 2.5 @Controller annotation and its companions, @RequestMapping, @RequestParam and @ModelAttribute will have noticed that it’s possible to map a request based on its HTTP method:

@RequestMapping(method = RequestMethod.POST)
 

This already "smelled" REST-like, so I guess it was just consequential to use Spring MVC as base for the upcoming REST support in Spring 3.0. I had the opportunity to talk about it with Arjen and he explained that they were actually experimenting with various concepts for doing this in Spring WS, but in the end, Spring MVC felt like the more natural choice.
But what will it look like then? Extend a welcome to…

UriTemplate and @PathParam
Well, actually @PathParam might not be the final name, I’ve also seen @UriParam somewhere, but the usage will be the same. I’ll just give you an example:

@RequestMapping(value = "/gadgets/{id}",
      method = RequestMethod.GET)
public View getGadget(@PathParam String id) {
  // Fetch a gadget by id and
  // return its representation as view
}
 

It can’t possibly get easier that that. Best of all, you can reuse your investment in Spring MVC because the programming model doesn’t change. The final release will include support for binding to more than one URI wildcard as well as identification of the requested representation based on HTTP Accept headers (for machine clients) or file extensions (for browsers).

Additional feature will include:

  • Using the Spring WS OXM support for creating XML views for requested resources
  • Additional views including AtomView, RssView and probably JsonView, too
  • Automatic generation and evaluation of HTTP ETag Header entries for caching purposes implemented as servlet filter
  • Interpretation of hidden form fields as HTTP method (as HTML only allows GET and POST in forms) by means of a servlet filter

You might wonder whether there will be any support for building REST clients as well. Indeed there is, and it’s - not much of a surprise here - …

RestTemplate
You can expect the usual usage patterns here and Arjen showed some actual code, so it’s pretty clear what the API (which by the way seems to be implemented on top of Commons HttpClient) is going to look like. I’ll just give a few examples based on Arjen’s slides here:

// Retrieving a represenation with
// getForObject (with parameter substitution)
RestTemplate template = new RestTemplate();
Gadget gadget = template.getForObject(
    "http://www.springify.com/gadgets/{id}",
    Gadget.class, 1);

// Creating a resource with postForLocation
// (with parameter substitution, map variant)
Map<String, String> params =
    new HashMap<String, String>();
params.put("id", 42);
URI uri = template.postForLocation(
    "http://www.springify.com/gadgets/{id}/features",
    new Feature("Glows in the dark."), params);

// Deleting a resource with delete
template.delete(
    "http://www.springify.com/gadgets/{id}", someId);

// … and the obligatory callback pattern, albeit without
// further details yet. Method parameter will be provided
// in the form of Enum types.
template.execute(
    "http://www.springify.com/gadgets/42/feature/1",
    POST,
    aRequestCallback,
    aResponseCallback);
 

Looks pretty straightforward to me. So now that we know the "what", what about the "when". Well, there’s some good news here. The first two features, namely RestTemplate for building clients and @PathParam for mapping to UriTemplate wildcards will be available in Spring 3.0 M1, which is scheduled for July or August. The remaining features will follow while Spring progresses towards 3.0 GA in late 2008.

What’s left
Well, there’s the issue of authentication and authorization, which is apparently taken care of by the Spring Security team. Arjen mentioned support for configuring access restrictions based on both HTTP methods and URLs, but I don’t have any details here.

That’s it for tonight as it’s getting late and I need to catch the train back home early tomorrow. I hope to post a summary of the SpringSource Application Platform sessions early next week, so keep an eye on the feed.

I wouldn’t go as far as to call the SpringSource team secretive, but they sure are building up tension with regards to the Spring 3.0. The talk I expected to provide a roadmap and feature summary actually did focus on version 2.5 feature. I wrote about some of the more interesting points here. I tried, however, to collect the various bits of information about the 3.0 release, so here you go (just remember that most of this could still be subject to change and shouldn’t be considered official):

Timeline
According to Jürgen, there’s the plan to have a first milestone by August 2008, although I’ve also heard July mentioned. If everything goes well, we might see a GA release late in Q4 2008.

Theme
Actually, Spring 3.0 will probably intensify what Spring 2.5 started: the embrace of the Java 5 programming model, this time to the extend that the Spring Core itself will be partially rearchitected and for the first time depend on Java 5. Internal (and gracefully downgrading) usage of Java 6 features will be expanded, although where and what was not announced. Also, there seems to be the trend to generalise certain parts of non-core modules in order to incorporate them into the core - for more about this see below.

Features
Well, there was not an aweful lot of information availabe about new features planned for 3.0 (with the exception of RESTful Spring, I’ll blog about that later tonight when I’ve ordered my notes), but here you go:

  • Full scale REST support by means of additions to the Spring MVC API - already pretty detailed, and apparently going to be included in the first milestone release
  • Support for Unified EL (as seen in Spring Web Flow) - very likely part of 3.0, but no details given
  • Annotation support for declaring factory methods - as above
  • Support for Portlet 2.0 (JSR 286), including resource requests (ResourceServingPortlet) - as above
  • "Preparations" for Servlet 3.0 specification - sounded a lot like architectural preparations not visible to the "consumer"
  • Something to fill the gap between Spring Web Flow and Spring MVC - that sounded very vague
  • Inclusion (probably generalisation) of the repeat, retry and resume semantics provided by Spring Batch - was only hinted at, no details given
  • Inclusion of the OXM support provided by Spring WS - sounded pretty definitive, but no details given
  • Some kind of site definition language for the web stack - no idea whether this is more than a rumour
  • Model-based validation for use both in server and client - as above

There’s probably more planned, but I guess we’ll have to wait for the first milestone to get a detailed roadmap.

Important changes
The one apparent and rather fundamental change is that Spring 3.0 will no longer run on Java 1.4. Apparently most of the core is refactored to use generics, enumerations and variable argument lists. Apart from that, some pruning is going to happen:

  • Deprecated artifacts will be removed
  • Some artifacts will probably marked as deprecated as of Spring 3.0, including the traditional Spring MVC controller hierarchy and the old JUnit 3.8 based integration test class hierarchy.
  • Commons Attributes support will probably be removed because it doesn’t make too much sense in a Java 5 environment
  • Support for plain Toplink will probably removed from the core

According to Jürgen, the programming model itself will be 100% backwards compatible with Spring 2.5. The framework’s extension points will, however, be pruned to accomodate for the fact that some of them won’t make sense in a Java 5 environment. Jürgen mentioned 95% backwards compatibility with regards to extension points, so that shouldn’t be much of an issue.

That’s it for now, expect another posting about developing RESTful Spring applications with Spring 3.0 later tonight.

As all of you probably know of the nice new features that arrived with Spring 2.5, I’m going to concentrate on the “gems” I harvested from Jürgens presentation. As for the 3.0 stuff, I’m going to collect the various bits of information that seem to pop up in various talks and write about it once I find the time to put all the pieces of the puzzle together…

One of the main themes in Spring 2.5 has been the progression towards Java 5 and JEE 5 programming models (e.g. by means of annotation driven configuration options and support for JEE annotations). The other apparent trend was the advent of load-time weaving as alternative to the traditionally proxy-based AOP model in earlier Spring releases. As Jürgen explained the major features that have been introduces in this context, he mentioned a couple of not so obvious facts about Spring 2.5 that I’d like to relay to you:

Registering custom annotations for component scan
You can write your own stereotype annotations (yes, completely independent from the Spring annotations) and make the container automatically pick up your annotated components by supplying filters to the ClassPathBeanDefinitionScanner responsible for determining valid candidates. See the documentation for details. This sounds great for implementing domain-driven design principles by providing intention revealing annotations.

OpenJPA save point support
Spring’s OpenJpaVendorAdapter exposes OpenJPA’s extended EntityManager implementation. As Spring’s JpaTransactionManager has support for JDBC 3.0 savepoints, this eventually allows you to use OpenJPA’s save point semantics. I’ll make sure to give this a try and blog about how it works.

LTW mode for <tx:annotation-driven/>
All of you know about the annotation driven transaction demarcation, which is usually done by the application context scanning your classes for @Transactional and wrap them in Proxies. While this usually works great, there is, as various forum threads suggest, some amount of confusion regarding the limits of dynamic proxies, mainly when transaction propagation doesn’t work as expected with “class-internal” method calls. As I just learned, you can alleviate that problem by enabling load-time weaving via an agent or the custom classloader implementations that are bundled with Spring and configuring the transaction support with an additional attribute like shown here (ommiting the loadtime weaving configuration itself):

<tx:annotation-driven mode="aspectj"/>
 

Neat, isn’t it? Methods annotated with @Transactional will be augmented during load-time afterwards, no more proxies are needed.

Well, that’s it for now, I’m off to listen to Mark Fisher’s talk about Spring Integration.

After having won the battle against Antwerp rush hour traffic, I arrived just in time for this year’s SpringOne keynote. Considering the momentum the Spring Framework has gained since my last attendance in 2006, I shouldn’t have been surprised by the sheer number of people who were already swarming the Metropolis cinema complex. As Stephan just told us, some 400 people from 25 countries have registered. But back to what’s happening on screen right now:
Stephan just finished his introductory talk, which he mainly spent showing all the shiney features of Parleys, with the announcement that due to trademark issue, Javapolis will officially be renamed to Javoxx and handed off the microphone to Rod.
Rod’s just promised that the keynote he’s about to hold is going to address technical people and presented statistics which showed that recently Spring overtook EJB as requirement on the US job market. Also, Gartner and Forrester seem to be convinced that Spring is going to be the key framework for developing enterprise Java applications and middleware services.
A point that Rod doesn’t get tired to emphasise is that Spring is about choice. One important step into that direction was the comprehensive support for annotation-based configuration in Spring 2.5. Even while the syntax is new, using @Autowired and @Qualifier is equivalent to the autowiring by type and by name that has always been part of Spring’s configuration options. What’s new is the possibility to define own qualifier annotations by annotating them with @Qualifier, as shown on the example below.

@Qualifier
@Component
@interface Apac {
    // Implementation omitted
}

@Apac
public class SomeLocalizedService implements SomeService {
    // Implementation omitted
}

public class SomeConsumer {
    @Apac
    SomeService someService;
    // Implementation omitted
}
 

The framework will associate the custom annotations and use them to chose the proper instance instance for injection. This leads to using Spring annotations as “meta-annotations” (a term just coined by Rod) to build own sets of domain-specific annotations that turn classes they are applied to to Spring-managed components. Combined with the classpath scanning functionality included in Spring 2.5, you could - if you really wanted to - avoid writing any XML configuration at all.

As the keynote progresses, Rod’s stressing that one of the most important freebies you get when using Spring is the ability to secure your application by means of Spring Security (formerly Acegi Security). As we all happen to know by now, every time you used Acegi, a fairy died. The configuration was just horrible (someone compared it to strangling a dragon with bare hands, though I seem to have lost the link; speak up if its you) as it basically boiled down to writing bean definition for all the Acegi low level components. Spring Security comes with a custom namespace that (almost) solves this problem. Personally I still find it daunting, but I also think that the domain it applies to is important enough to use it nevertheless.

One thing Rod seems to be surprised of - and I’m with him there - is that almost no one in the audience uses the Spring integration testing framework provided by means of Spring TestContext. For those of you not attending SpringOne, I’m gladly relaying his invitation to give it a try and donate the money you save by doing so (to him, but that’s just an implementation detail you’re free to change). I gave an example of how to use it for test-driven development in a recent post.

Spring Integration is another new addition to the Spring Framework family. Considering that Spring has always been a strong integration platform, being able to use it as quasi service bus with a domain specific configuration language implementing Gregor Hohpe’s EAI patterns seems pretty convenient. I’m going to blog about this in detail in the near future, so I will not dig into the details here.

If you have used Spring MVC in Spring 2.0, you should also have a look at the new features introduced with the 2.5 release. I have written about it before, but I think the new “convention over configuration” mentality introduced here - especially with the advent of @Controller - is worth noting again. Things have become a lot easier and, combined with the new Spring Web Flow release, development web applications with Java might even become fun (well, in the broader sense). Some of the highlights of both frameworks, namely the aforementioned @Controller annotation, SWF’s Ajax features, Spring JavaScript (which is, according to Keith, who just took over the microphone, is “a toolkit for progressively enhancing web pages with AJAX” built on DOJO) and Spring Faces (which basically makes JSF as component framework available within Spring Web Flow driven applications and could be considered a JSF integration layer) found their way into the keynote.

With Rod back at the microphone, the topic now is deployment models and runtimes for Spring based application. He stresses that developing with the Spring programming models in fact decouples your code from the runtime environment, as Spring as container works in all deployment models available today (JEE, Servlet, OSGi, etc.). While portability on this level doesn’t seem like an issue, there’s the ongoing trend of deploying to to lightweight servlet containers like Tomcat and Jetty instead of commercial JEE containers. Whether or not OSGi will be the next generation enterprise runtime is yet to be determined, nevertheless the announcement of SpringSource Application Platform (I blogged about it here) last month seems to be an indicator for it’s relevance. Rob, Application Platform lead, just entered the stage with an awesome S2AP t-shirt (100% bloat-free); if I am able to get one of those, I’ll post a picture here.

Rod’s talking about the SpringSource Enterprise subscription now, which, besides official support (including indemnification), grants access to the SpringSource Tool Suite, an Eclipse-based integrated development environment for Spring-based applications. As of the latest developer release, the Tool Suite comes with support for the PAR deployment style introduced with S2AP. Even while I’m not that much of an Eclipse person, I will try to give you an overview of what’s being presented here. I also have to mention the incredible pace at which Christian, Spring IDE and STS lead, keeps up with the rapidly expanding and changing Spring stack. One interesting feature seems to be what Christian is calling “runtime error analysis”, which allows you to automatically look up stack traces in a knowledge base to find likely solutions to your programming problems. Actually STS incorporates a lot of what I’d call community features like forum access, recent news, etc. If you hate media disruptions as I do, this might be a good thing for you. Christian stresses that, due to the comprehensive context sensitive hints and the comprehensive knowledge about Spring best practices built into it, the Tool Suite can be used as a consulting and teaching platform for Spring based projects.
The subscription also lets you use the SpringSource Application Management Suite, which is a runtime monitoring platform for Spring applications with support for all major JEE containers as well as Tomcat. I leave it up to you to look up the details of this and the other SpringSource enterprise products (fingers are already hurting) and write about SpringSource’s goals and motivations as presented by Rod at this moment.

Interesting enough Peter Cooper-Ellis, former WebLogic Unit Excutive, has just been hired by SpringSource for Engineering and Product Management. He’s right now talking about his background with proprietary software and how the the whole industry is moving towards deployment scenarios like cloud computing. One of his roles at SpringSource seems to be to help the Spring framework meet the demands those trends will make on the next generation’s application frameworks.

Well, I think that’s about it for now. I’ll keep you posted about any ground-breaking news, so make sure to subscribe to the feed.