Spring in Action. Second Edition (Part 1. Core Spring)

Preface

It was December 7, 2005. I was standing at the side of a large hotel meeting room

in Miami Beach, Florida. The room was filled with developers from all over the

world who had descended upon the beautiful sandy beaches of southern Florida

for a single purpose: to talk about Spring.

What can I say? It was a room full of nerds. Rather than soak in the sun and

surf, we all gathered inside to bask in the warm glow of our laptop screens to learn

more about our beloved framework from those who know it best.

On that particular night, we were hanging on the words of Spring’s creator,

Rod Johnson, as he presented the opening keynote for the conference. He spoke

of Spring’s origins and the successes it had enjoyed. Then he invited a few members

of the Spring team to the podium to introduce new features that were to be

in the next version.

He wasn’t far into his presentation when Rod made an announcement that

caught everyone’s attention. We were all expecting these great new features to be

available in Spring 1.3, the supposed next version of Spring. Much to our surprise,

Rod informed us that there would be no Spring 1.3; the next version would be

Spring 2.0.

The decision to bump up the major version number of the next release isn’t

made lightly. Such an action connotes a significant advance in Spring. If the next

version of Spring would be 2.0, then we could expect major enhancements.

Indeed, ten months later, Spring 2.0 would be released with an abundance of new

capabilities, including:

• Simplified XML configuration and the option to create custom configuration elements

• Greatly simplified AOP and transactions

• Support for Java 5 annotations for declaring aspects, transactions, and required bean properties

• The ability to create beans from scripts written in JRuby, Groovy, or Bean-Shell

• New JDBC templates to support named parameters and Java 5 features

• Improved JMS support, including receiving messages asynchronously (for creating message-driven POJOs)

• A new form-binding JSP tag library

• Several convention-over-configuration improvements to reduce the amount of XML required to configure Spring

• Support for the Java Persistence API (JPA)

• Enhanced bean scoping, including request and session scoping of beans for web applications

• The ability to perform dependency injection on objects that Spring doesn’t create (such as domain objects)

At one point in his keynote, Rod said that if the wealth of new features being

introduced didn’t justify a jump to 2.0, then how would they ever be able to justify

a 2.0 release?

That’s not all. In addition to the work being done on the core Spring Framework,

several interesting Spring-related projects were underway to provide additional

capabilities on top of Spring. Among them:

• Spring Web Flow, which is based on Spring MVC and enables development of flow-based web applications

• XFire, for exporting your Spring beans as SOAP web services

• Spring-WS for creating contract-first web services

• Spring Modules, which provides (among other things) declarative caching and validation

• Direct Web Remoting (DWR) for Ajax-enabling Spring beans

• Lingo, which makes it possible to asynchronously invoke methods on remote beans

Then it occurred to me: if all of these new advances in Spring didn’t justify a second

edition of Spring in Action, then what would? As it turned out, Manning was

thinking the same thing.

And now, well over a year later, here’s the long-awaited update to Spring in

Action that covers many of the new features of Spring 2.0. It has taken me a lot

longer to finish than I had planned, but I hope that it was worth the wait. My goal

for this edition is the same as with the first: to share the joy of developing in

Spring. I hope this book will serve to enhance your enjoyment of Spring.

Preface to the first edition

Software developers need to have a number of traits in order to practice their

craft well. First, they must be good analytical thinkers and problem solvers. A

developer’s primary role is to create software that solves business problems.

This requires analyzing customer needs and coming up with successful, creative

solutions.

They also need to be curious. Developments in the software industry are moving

targets, always evolving. New frameworks, new techniques, new languages, and

new methodologies are constantly emerging. Each one is a new tool that needs to

be mastered and added to the toolbox, allowing the developer to do his or her job

better and faster.

Then there is the most cherished trait of all, “laziness.” The kind of laziness

that motivates developers to work hard to seek out solutions with the least amount

of effort. It was with curiosity, a good dose of “laziness,” and all the analytical abilities

we could muster that the two of us struck out together four years ago to find

new ways to develop software.

This was the time when open source software was reaching critical mass in the

Java community. Tons of open source frameworks were blossoming on the Java

landscape. In order to decide to adopt one, it had to hit the sweet spot of our

needs—it had to do 80% of what we needed right out of the box. And for any

functionality that was not right out of the box, the framework needed to be easily

extendible so that functionality too would be included. Extending didn’t mean

kludging in some hack that was so ugly you felt dirty afterwards—it meant extending

in an elegant fashion. That wasn’t too much to ask, right?

The first of these frameworks that gained immediate adoption on our team

was Ant. From the get-go, we could tell that Ant had been created by another

developer who knew our pain in building Java applications. From that moment

on, no more javac. No more CLASSPATH. All this with a straightforward (albeit

sometimes verbose) XML configuration. Huzzah! Life (and builds) just got easier.

As we went along, we began adopting more and more tools. Eclipse became

our IDE of choice. Log4J became our (and everybody else’s) default logging toolkit.

And Lucene supplanted our commercial search solution. Each of these tools

met our criteria of filling a need while being easy to use, understand, and extend.

But something was lacking. These great tools were designed to help develop

software, like Ant and Eclipse, or to serve a very specific application need, like

searching in the case of Lucene and logging for Log4J. None of them addressed

the needs at the heart of enterprise applications: persistence, transactions, and

integration with other enterprise resources.

That all changed in the last year or so when we discovered the remarkable onetwo

enterprise punch of Spring and Hibernate. Between these two frameworks

nearly all of our middle- and data-tier needs were met.

We first adopted Hibernate. It was the most intuitive and feature-rich object/

relational mapping tool out there. But it was by adopting Spring that we really got

our code to look good. With Spring’s dependency injection, we were able to get

rid of all our custom factories and configurers. In fact, that is the reason we first

integrated Spring into our applications. Its wiring allowed us to streamline our