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

In a past life I did a lot of work in configuration management and build systems. When I started here at Interface21, I immediately volunteered to help out with the build infrastructure as much as I could. Next thing I know, I've got every single ticket relating to Maven in both Spring and Spring Web Flow assigned to me. Then through my own lackadaisical attitude towards the JIRA, I let this particular issue come to a boil. Over the past couple of months, things have been moving forward with regards to Spring and Maven; things I should have posted in the JIRA and didn't. This led to some justifiable venting in the main JIRA issue over the last couple of days. So in an effort to bring everyone up to speed here's the current status.

Status

For those of you who have been in despair over the last couple of months about Spring 2.0 and Maven, you won't be for much longer. The Spring community has decided to incrementally convert all of the Spring projects over to Maven. As you may know Acegi has already been using Maven for a very long time. Recently the Spring-WS project converted as well. I've personally prototyped Spring Web Flow's conversion, and there is general agreement that Spring will move over as well.

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.

So what's the plan?

It's pretty simple actually. For both Spring and Spring Web Flow I'll be building up POMs with the dependency lists by hand over the next couple of weeks. At this time the plan is to release these POMs with the final releases of both Spring and Spring Web Flow. After the releases, with Arjen's help I'll be assisting both Juergen and Keith in converting their source trees over to Maven builds and getting those builds running in Continuum.

Then what can I, the user, do in the meantime?

Well the first thing is to be patient. It's my fault that we've been silent on this issue so long and hopefully this post will give some transparency to our thought process. Secondly, I'd love help testing. My plan is to check-in the trial POMs to CVS and SVN as I'm working, and announce on the JIRA issues that changes have been made. As you'd guess, the creation of POMs by hand is error prone (one of the driving factors towards a Maven build), so I'd love for some help testing them. Comments in the JIRA, posts to the forum, and posts to the developers mailing list are all good avenues for feedback.

Anything else you want to know about?

Again, I hope this helps alleviate some of the frustration in the community and gives you an idea of our future direction. Any comments on this current plan are of course welcome (the comments here would be a good spot for that), but I'd also like to know if you have any other questions or issues that you're frustrated by. If you leave a question below or email me directly, I'll try to get you a good answer and either post it here on the blog or email it back to you personally.

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…

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…

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…

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

There are three primary BeanDefinitionParsers that Spring provides to help you parse your XML namespaces.

• AbstractBeanDefinitionParser
  • AbstractSingleBeanDefinitionParser
    • AbstractSimpleBeanDefinitionParser

I'm going to start at the most specific and work towards the most general to show how to gain more power when you need it. If you want to skip the examples and see the summary, check here…

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…

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

Of all the new Spring 2.0 features and improvements, I must admit that Message-Driven POJOs are one of my personal favorites. I have a feeling that a lot of other Spring users will feel the same way.

Here I am providing a quick introduction. There is a lot more to show, and I will follow this up with other posts. For now though - this should provide you with enough information to get up and running with some truly POJO-based asynchronous JMS! I hope you are as excited about that as I am ;)

Prerequisites:

You will need the following JAR files on your classpath. I've also listed the versions that I am using (any spring-2.x version should be fine. I just dropped RC3 in there about 2 minutes ago in fact):

• activemq-core-3.2.2.jar
• concurrent-1.3.4.jar
• geronimo-spec-j2ee-managment-1.0-rc4.jar
• commmons-logging-1.0.4.jar
• log4j-1.2.9.jar
• jms-1.1.jar
• spring-2.0-rc3.jar

Setup the Environment

First, we need to setup the environment. I am going to be using ActiveMQ, but the impact of changing a provider will be limited to modifications within this one file. I'm calling this file "shared-context.xml" since as you will see shortly, I am going to be importing these bean definitions for both sides of the JMS communication. Here are the "shared" bean definitions: the connection factory and two queues (one for the requests and one for replies):

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
                           http://www.springframework.org/schema/beans/spring-beans.xsd">
	
    <bean id="requestQueue" class="org.activemq.message.ActiveMQQueue">
        <constructor-arg value="requestQueue"/>
    </bean>
 
    <bean id="replyQueue" class="org.activemq.message.ActiveMQQueue">
        <constructor-arg value="replyQueue…

An article I wrote for the InfoQ site has just gone live: Simplifying Enterprise Applications With Spring 2.0 and AspectJ.

I've heard a number of people saying that "AOP is too hard", or "AOP makes things too complex". In a way this article was written as a rebuttal of those views (hence the title, "Simplifying Enterprise Application Development"). I mean, the whole point of AOP is that you take software that was getting complex and tangled up, and you simplify the implementation by giving each module a single responsiblity again by introducing aspects. And then of course for some…