The Spring Blog

Spring Framework 2.0 RC4 has been released. This is the last release candidate before Spring 2.0 final, and you may find out more about it from the release announcement itself as well as the JIRA issue list for a complete list of changes in this release.

Possibly the most important thing to watch out for is that this release introduces versioned file/location names for the 2.0 DTD and Schemas (XSDs). This was necessary since the XML bean definition format was significantly enahnced for 2.0, but 1.2.x users still need to be able to refer to the 1.2.8 DTD. Here is an example of using the 2.0 “beans” schema (2.0 ships with a number of other new schemas as well, representing various special namespaces):

We are pleased to announce that Spring 2.0 RC4 has been released.  Download | Documentation | Changelog

This is the last release candidate before Spring 2.0 final.  RC4 includes many further bug fixes and refinements in various areas, as well as minor new features (for example in the JMS support). Please see the changelog and JIRA issue list for all the details.  The most notable changes include…

New and Noteworthy

• This release introduces versioned file names for the 2.0 DTD and XSDs. Please adapt your bean definition files if they build on the 2.0 XSDs on or 2.0-specific DTD features.  For example:
  

Can you guess what it is? If you guessed a Maven bundle/build for Spring you win. Come see me at The Spring Experience in December and we’ll share a frosty beverage as your prize.

Mea Culpa

Status

That said, it’s not quite time for celebration. Converting the last two projects (Spring and Spring Web Flow) are non-trivial tasks (just take a look at Better Builds with Maven if you don’t believe me). As such, the conversion is not something that we really want to do this close to the major 2.0 and 1.0 releases. What I can tell you is that the conversion is a goal scheduled for after the releases.

It started out as a small thing. Just a hunch of mine that Spring and OSGi should sit together very well. The idea was that by enabling Spring applications to be deployed in an OSGi runtime, we could bring better modularity, versioning, runtime deployment and update capabilities to Spring applications. It’s a project I never really advertised; I just started experimenting, talking to a few people, and writing some early prototype code.

It turns out that a lot of people seem to be interested in Spring and OSGi. We have a collaboration ongoing with representatives from BEA, Oracle, IBM, Eclipse, the OSGi Alliance, and several others to build a shared model of how Spring support for OSGi should look, and how we can make it easy to build enterprise applications on the OSGi runtime. The most recent version of the specification is attached to Spring JIRA issue 1802. Here’s a direct link to the specification text. I ran a workshop in London a couple of weeks ago where we got several of the key players together and made some excellent progress. Peter Kriens (OSGi Technical Director) has a write-up here.

As most of you know, one of the big improvements in Spring 2.0 is the addition of the AspectJ pointcut language and better integration with AspectJ in general. While I think everyone believes that this will be a great benefit in the long run, it has led to some issues. We’ve found that there are certain behaviors that Spring AOP has always done, that AspectJ has never done.

One of the big issues that cropped up was the behavior of Before advice. If you’ve used Spring AOP in Spring 1.x you probably know that Spring allows you to change argument values before they are passed to the target method. What you may not know is that AspectJ has never allowed this behavior.

Spring - here to stay for a long time
I visit many clients and speak to even more on a day-to-day basis. This includes existing Interface21 clients as well as companies that are interested in our products and services across Europe. I have noticed a recurring theme in the conversations I am having: Spring is here, and it is here to stay.

Over the last year I have witnessed executive-level decisions that have standardized Spring throughout the fabric of leading Enterprise Java development firms. Just two weeks ago I asked one of my clients - a Java unit manager at one of Europe’s largest System Integrators - “what could cause you to move away from Spring?” His answer was crystal clear, “At this time, nothing. With our level of investment it would take us at least a couple of years to analyze and test the feasibility of any alternative.”

Dear Spring Community,

We are pleased to announce that Spring LDAP version 1.1 has been released. This is the first release of the library as a Spring Framework sub project. Download | Documentation | API

About Spring LDAP
Spring LDAP is a Java library for simplifying LDAP operations, based on the pattern of Spring’s JdbcTemplate. The framework relieves the user of the burden of looking up and closing contexts, looping through NamingEnumerations, encoding/decoding values and filters, and more.

The LdapTemplate class encapsulates all the plumbing work involved in traditional LDAP programming, such as creating, looping through NamingEnumerations, handling Exceptions and cleaning up resources. This leaves the programmer to handle the important stuff - where to find data (DNs and Filters) and what do do with it (map to and from domain objects, bind, modify, unbind, etc.), in the same way that JdbcTemplate relieves the programmer of all but the actual SQL and how the data maps to the domain model.

Lately it seems like I’ve been focusing on creating Spring XML namespaces. It’s been a lot of trial and error (both on the XSD and Spring side) to get a good pattern for creating parsers. One of the biggest confusions that I ran into was the AbstractBeanDefinitionParser hierarchy. At this point it isn’t documented especially well (but there is a JIRA for it, so it’ll be fixed before GA), so I’ll give you a rundown of your choices, what they’re good for and how to use them.

AbstractBeanDefinitionParser choices

Hey all!

This is my first post since I joined Interface21 last month. My previous blog is now officially deprecated and I won’t be updating it anymore.

So what is the subject of my first post (except to introduce myself)?  Validation logic.  It won’t be a walkthrough of how to perform validation in the Spring framework, rather it will discuss a particular bug bear of mine :)

In particular, I would like to discuss exactly what should go into validation logic.  It seems to be a no-brainer answer; “logic to validate the specified data”.  OK, that is a no-brainer but read on :).
As you know, the Spring framework provides a nice abstraction layer for your validation, via the Errors and Validator interfaces.  In particular the Validator is where you apply your business specific validation rules to your populated domain object.  Spring’s excellent binding support is responsible for updating your domain model based on some input, the validator is responsible for ensuring that the populated domain model is semantically correct.
So what is my bug bear?  Time and time again I keep running across applications that allow validation logic to trickle out of the validator and into the controllers (for web apps), or even worse into the middle tier.  Just before people start taking issue; I am not saying validation doesn’t belong in the middle tier, I am saying that the Validator is the place to put validation logic!

Hello all,

This is just a quick entry to let you know I have officially relocated my biz.blog to here, our new Interface21 team blog.  I’m excited about this group blog serving as the voice of Interface21.  For those of you who know me, you know to expect a different perspective.

I have got some saved drafts I am working on. Watch for new entries that provide insight into the business aspects of Interface21 soon…

Until then,
Steven