The Spring Blog

As Interface21 grows as a global company one thing has become more and more clear to me everyday:

we really have some damn talented, highly motivated leaders who have a lot to say on both business and technology.

Here you will gain insight into what’s going on at i21, from what we’re working on, to what problems we’re solving, to where we’re going, to what we’ve learned along the way. You’ll see a lot of diversity, as our company is doing a lot of things, from leading the development of the Spring Framework and the Spring family of products to expanding operations in five major international markets.

The motivation behind this blog entry is to provide a simple step-by-step guide for getting started with JPA in a standalone environment with the Spring Framework. While the JPA specification originated as the persistence mechanism for EJB 3.0, it was fortunately recognized that any such mechanism should in fact be able to persist simple POJOs. Therefore, with a handful of JARs in your classpath and a few Spring-configured beans, you can begin experimenting with JPA code within your favorite IDE. I will be using Glassfish JPA - which is the reference implementation and is based upon Oracle's TopLink ORM framework.

I just got finished with my Spring 2.0: New and Noteworthy talk at Atlanta DevCon 2006. Let me be the first to say that the conference was great. The site and organizers were all top notch. I’d like to give a special shout-out to Burr Sutter for putting on one heck of a conference. You know that things are going well when the conference center doesn’t have a wireless network but you can get the one from the cafe next door. That’s good karma! The JUG members were all very knowledgeable (even the ones that didn’t know about Spring) and asked great questions. I fielded questions about EJB 3, JPA, ESB, Spring learning curves, Java 5, and Spring Web Flow; every one a great question.

In a project that I used to work on we had a system that would receive messages from a device and make decisions on whether that information would be passed to the user. There were multiple decision levels and one of the problems we always found ourselves asking was if a message was being lost on it’s way through the system.

Before we moved to Spring, it was nearly impossible to tell the answer to that question. Attempts were made to use logging, but the sheer volume of messages that decisions were made on made it tedious at best. Other attempts were made using debuggers but a combination of the volume and the timing changes led to only intermittent success.

Recently I was working on a project that had a Swing client communicating via RMI to a service layer. The service layer was marked with transactions and everything seemed to work fine. However everytime we’d get an exception at the Hibernate DAO layer, Spring would turn the exception into a runtime exception and it would get propagated all the way up the stack and across the RMI connection as a RemoteException. Whenever the exception was deserialized there would be an exception on the client (separate from the RemoteException.The decision was taken to simply introduce an aspect. Any exception that subclassed ServiceAccessException would be let through to the client while anything else would be converted to a FilteredServiceAccessException (a subclass of ServiceAccessException) and then be thrown. This led to some loss in content, so we made sure to log the original exception on the server where it could be useful and let the client show a generic dialog so the user knew generally what had happened.

With the release of Spring 1.1 the Spring community was given it’s first taste of JMS support. This support included exception translation, message conversion, and a template class much like JdbcTemplate. This support also took care of domain unification between the JMS 1.0.2 and 1.1 specs. The centerpieces of this support are the JmsTemplate class and it’s JMS 1.0.2 counterpart JmsTemplate102.

This support was a great improvement over using the raw JMS APIs to do enterprise messaging. However it did have a shortcoming; the JmsTemplate only supported synchronous reception of messages using the JmsTemplate.receive() methods. This behavior worked well for many people but the vast majority of users of ended up rolling their own implementations of an asynchronous consumer. In short, they wanted what EJB 2 called Message Driven Beans.

While the material in this post is quite simple, it will actually offer a glimpse of some rather significant new features in Spring 2.0. I hope that with a little imagination, you will be able to apply what you see here to far less trivial use cases of your own.

I am going to show 2 examples actually. The first will use a rather simple logger:

package example;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class SimpleLogger {

  private static Log log = LogFactory.getLog(SimpleLogger.class);

  public void logOneString(String s) {
    log.info("string=" + s);
  }

  public void logTwoStrings(String s1, String s2) {
    log.info("string1=" + s1 + ",string2=" + s2);
  }
}

Over 200 people registered to attend the inaugural Sydney Spring User Group meeting, which was held on 22 February 2006. As shown by the photos (below), there was standing room only, and several attendees flew in from interstate for the evening.

With one-third of those attending indicating they do not presently use Spring, Rod Johnson's “Introduction to Spring” presentation was well-received and motivated many questions. The planned “Spring 2.0 and Beyond” talk – which undoubtedly will be of keen interest to those who are currently using Spring – was rescheduled until the next meeting.

A couple of months ago, in the days before I had a blog, there was a discussion by Cedric and Bob about “Getter Injection.”

The basic concept is that the IoC container can override abstract or concrete methods on managed objects on deployment. The container is injecting a method, such as a getter method, rather than a reference or primitive as in Setter Injection. As it happened, I was already working on a container method override mechanism for Spring 1.1, which has since been released in Spring 1.1 RC1. It’s an interesting concept, and definitely part of a complete IoC container. However, I believe that the concept is more general and needs a more general name. Also, that it should only be used in a fairly narrow range of scenarios.