The Spring Blog

Engineering
Releases
News and Events

Getting Started With JPA in Spring 2.0

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.

Read more...

Atlanta DevCon 2006

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.

Read more...

Message Flow Tracing with AspectJ and JMX

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.

Read more...

Another Reason to Love Spring 2.0: Interceptor Combining

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.

Read more...

Spring 2.0's JMS Improvements

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.

Read more...

POJO Aspects in Spring 2.0: A Simple Example

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); } }
Read more...

Inaugural Sydney Spring User Group Meeting

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.

Read more...

Method Injection

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.

Read more...