Wrox professional java development with the spring framework jul 2005 ISBN 0764574833 pdf

Professional Java Development with the Spring Framework
byRod Johnsonet al.
John Wiley & Sons 2005 (672 pages)
ISBN:0764574833

Written by the lead developers of the Spring Framework, this authoritative guide shows you not only what
spring can do but why, explaining its functionality and motivation to help you use all parts of the
framework to develop successful applications.

Table of Contents
Professional Java Development with the Spring Framework
Introduction
Chapter 1

- Introducing the Spring Framework

Chapter 2

- The Bean Factory and Application Context

Chapter 3

- Advanced Container Concepts

Chapter 4

- Spring and AOP

Chapter 5

- DAO Support and JDBC Framework

Chapter 6

- Transaction and Resource Management

Chapter 7

- Object/Relational Mapping

Chapter 8

- Lightweight Remoting

Chapter 9

- Supporting Services

Chapter 10 - Acegi Security System for Spring
Chapter 11 - Spring and EJB
Chapter 12 - Web MVC Framework
Chapter 13 - Web View Technologies
Chapter 14 - Integrating with Other Web Frameworks
Chapter 15 - The Sample Application
Chapter 16 - Conclusion
Appendix A - Requirements for the Sample Application
Index
List of Figures
List of Sidebars

Back Cover
The Spring Framework is a major open source application development framework that makes Java/J2EE
development easier and more productive. This book shows you not only what spring can do but why, explaining its
functionality and motivation to help you use all parts of the framework to develop successful applications.
You will be guided through all the Spring features and see how they form a coherent whole. In turn, this will help
you understand the rationale for Spring’s approach, when to use Spring, and how to follow best practices. All this
is illustrated with a complete sample application. When you finish the book, you will be well equipped to use
Spring effectively in everything from simple Web applications to complex enterprise applications.
What you will learn from this book
The core Inversion of Control container and the concept of Dependency Injection
Spring’s Aspect Oriented Programming (AOP) framework and why AOP is important in J2EE development
How to use Spring’s programmatic and declarative transaction management services effectively
Ways to access data using Spring’s JDBC functionality, iBATIS SQL Maps, Hibernate, and other O/R mapping
frameworks
Spring services for accessing and implementing EJBs
Spring’s remoting framework


Professional Java Development with the Spring
Framework
Rod Johnson
Juergen Hoeller
Alef Arendsen
Thomas Risberg
Colin Sampaleanu
Professional Java™ Development with the Spring Framework
Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard

Indianapolis, IN 46256
www.wiley.com
Copyright © 2005 by Wiley Publishing, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN-13: 978-0-7645-7483-2
ISBN-10: 0-7645-7483-3
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
1B/RV/QW/QV/IN
Library of Congress Cataloging-in-Publication Data:
Professional Java development with the Spring Framework/Rod Johnson
...[et al.].
p. cm.
Includes index.
ISBN-13: 978-0-7645-7483-2 (paper/website)
ISBN-10: 0-7645-7483-3 (paper/website)
1. Java (Computer program language) 2. Application software
–Development. I. Johnson, Rod, Ph.D.
QA76.73.J38P74585 2005
005.13'3–dc22
2005013970
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by
any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted
under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written
permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the
Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 6468600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley
Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or
online at />LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO
REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS
OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING

WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY
MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND
STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK
IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING


LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE
IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE
SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES
ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN
THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES
NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE
ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER,
READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE
CHANGED OR DISAPPEARED BETWEEN THEN THIS WORK WAS WRITTEN AND WHEN IT IS
READ.
For general information on our other products and services please contact our Customer Care Department
within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 5724002.
Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Programmer to Programmer, and related trade
dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United
States and other countries, and may not be used without written permission. Java is a trademark of Sun
Microsystems, Inc. All other trademarks are the property of their respective owners. Wiley Publishing, Inc.,
is not associated with any product or vendor mentioned in this book.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
not be available in electronic books.
About the Authors
Rod Johnson is the founder of the Spring Framework and a well-known expert on Java and J2EE.
Rod holds a Ph.D. from Sydney University. Originally from a C/C++ background, he has been involved with
Java and J2EE since their releases as a developer, architect, and consultant.
He is the author of two of the most popular and influential books on J2EE: Expert One-on-One J2EE

Design and Development (Wrox, 2002), and J2EE without EJB (Wrox, 2004, with Juergen Hoeller). Both
have played a major role in the rise of "agile" J2EE, and the move away from overly complex traditional
J2EE architecture.
Rod is co-lead of the Spring Framework. He is a popular conference speaker and regularly appears at
leading Java events in the US, Europe, and Asia. He serves in the Java Community Process (JCP) on the
expert groups of several JSRs.
He also has wide consulting experience in banking and finance, insurance, software, and media. He is
CEO of Interface21 (www.interface21.com), a consultancy devoted to providing expert J2EE and
Spring Framework services. He is actively involved with client projects as well as Spring development.
For Kerry.
Juergen Hoeller is co-founder of Interface21, the company providing commercial Spring services from the
source. He is a key driver of Spring development and has been release manager since Spring's inception.
His special interests and responsibilities in the project cover a wide variety of topics, from the core
container to transaction management, data access, and lightweight remoting.
Juergen has a Master's degree in computer science from the University of Linz, specializing in Java, OO
modeling, and software engineering. He is co-author of Expert One-on-One J2EE Development without
EJB (Wiley, 2004) and regularly presents at conferences and other events. He is also active in many
community forums, including TheServerSide.
To Eva, for her continuing love and support, and for understanding that there is no separation
between working time and spare time in the Spring world.
Alef Arendsen studied computer sciences at the University of Utrecht. Later, also in Utrecht, Alef started
his first company. After this turned out to be too little a challenge, Alef went to work for SmartHaven, an
Amsterdam-based VC- funded company providing J2EE components for knowledge management


applications. He was responsible for streamlining the development process and designing parts of the
component infrastructure. In early 2002, together with Joost van de Wijgerd, Alef founded JTeam, a
software company providing J2EE development services. Alef is a core Spring committer and, while
remaining involved with JTeam, he is now a consultant for Interface21. He is a frequent speaker at public
conferences. Alef can be reached by email at You can also read his blog at

.
To Mas, my nephew, who frequently cheered me up and reminded me of things other than work.
Thomas Risberg is a database developer working for TargetrRx, a pharmaceutical market research
company located in Horsham, Pennsylvania. He has many years of experience working with both large and
small organizations on various database-related projects ranging from simple data entry programs to large
data warehousing implementations. Thomas is a reformed COBOL programmer who came to Java via
Xbase, Visual Basic, and PL/SQL. He served as an Oracle DBA for a couple of years but decided that
software development was really where his heart was.
Thomas has a B.A. degree in information processing from the University of Stockhom, Sweden. He is a
certified Oracle Professional DBA and a Sun Certified Java Programmer and J2EE Architect.
Thomas joined the Spring Framework development team in early 2003 and is mostly involved in evolving
the JDBC layer. His non-computer–related interests are soccer, photography, and travel.
Colin Sampaleanu has had a long and varied career spanning almost two decades—after a childhood
spent tinkering with computers and software—including experience developing for and managing his own
retail software company, other years in the C++ shrinkwrap and enterprise software space, experience with
Java since the early days of the language, and a complete focus on enterprise Java since the late nineties.
Colin is a currently a principal partner at Interface21, which specializes in Spring training, consulting, and
support. Prior to joining Interface21, Colin was Chief Architect at a software incubator / VC.
As a core Spring developer and Interface21 principal, Colin spends much of his time talking and writing
about the benefits of Spring, and promoting agile software development architectures and methodologies
in general.
To Nina, for her continued love and support, and for understanding that despite our best intentions,
in this field 9–5 is often just the first half of the workday. To Alec and Maia, for their simple
innocence and joy, and for reminding me that there are other things in life besides computers.
Credits
Executive Editor
Robert Elliott
Development Editor
Adaobi Obi Tulton
Technical Editors

Peter den Haan
Qi Zhang
Aleksandar Seovic
Erik Janssens
Copy Editor
Nancy Rapoport
Editorial Manager
Mary Beth Wakefield
Vice President & Executive Group Publisher
Richard Swadley
Vice President and Publisher


Joseph B. Wikert
Project Coordinator
Kristie Rees
Graphics and Production Specialists
April Farling
Julie Trippetti
Quality Control Technicians
Leeann Harney
Jessica Kramer
Joe Niesen,
Carl William Pierce
Proofreading and Indexing
TECHBOOKS Production Services
Acknowledgments
Rod Johnson: Many people helped in the writing of this book. In particular, I thank my co-authors, each of
whom played a valuable role in ensuring that we were able to achieve coverage of a wide range of Spring's
large and growing feature set.

Thanks to Ben Alex, lead developer of Acegi Security for Spring, for contributing most of the material on
Spring security. Mark Pollack, Spring developer and lead of Spring.NET, also kindly contributed valuable
material relating to
Spring's services for JMS. Dmitriy Kopylenko, also a Spring developer, helped with UML diagrams and
examples for the AOP chapter.
Finally, thanks to the reviewers—especially Peter den Haan and Aleksander Seovic—for their attention to
detail and many valuable suggestions.
Juergen Hoeller: I thank my co-authors, our reviewers, and our editor; it has been a pleasure working with
you. A special thank you goes to Peter den Haan for his extraordinarily thorough chapter reviews. Last but
not least, I express my gratitude to the entire Spring community: Without your active participation, the
Spring project would not be what it is today.
A. Arendsen: I thank all my co-workers at JTeam for their support. Special thanks to Bram Smeets and
Arjen Poutsma for providing valuable content on various topics. I also owe a lot to Joost, the chap I
originally started JTeam with. Without him I couldn't have found the time to contribute to this book. I also
want to express my gratitude to Goof Kerling, who taught me a great deal about programming, how to do it
the right way, and life in general. Thanks to Lars for cooking once every month, providing me with a place
to stay until my house was finished, and joining me for the occasional beer. Also, thanks to my family for
their support and the technical editors for thoroughly reviewing the content and for pointing out that Dutch
isn't the most widely used language in the world.
Thomas Risberg: I thank the entire Spring community—without you, neither the project nor this book
would be what it is today.
Colin Sampaleanu: I thank my co-authors, my partners at Interface21, and the Spring team for setting the
bar so high. It's always a pleasure working with you. I'm grateful for the many colleagues over the years
who by being passionate about the art of software development have helped keep my own interest high. I
also thank my technical reviewers, Peter den Haan, Qi Zhang, and Jim Leask, who provided much
valuable feedback.


Introduction
The Spring Framework is a major open source application development framework that makes Java/J2EE

development easier and more productive.
Spring offers services that you can use in a wide range of environments, from applets and standalone
clients through web applications running in a simple servlet engine to complex enterprise applications
running in a full-blown J2EE application server. Spring enables a POJO programming model that
decouples your code from its environment, protecting your investment in the face of change. Spring works
on JDK 1.3 and later, taking advantage of JDK 1.4 and 1.5 features if available. Spring's J2EE services
run on J2EE 1.2 and later.
This book will show you how you can use all the major parts of Spring to help you develop successful
applications. You'll learn not just what Spring does, but why. You will gain insight into best practices when
using the framework, and you will see a complete sample application.

Whom This Book Is For
This book is for Java/J2EE architects and developers who want to gain a deep knowledge of the Spring
Framework in order to use it effectively in applications from simple web applications up to complex
enterprise applications.
If you're new to Spring, you will still be able to work your way through this book. However, the coverage of
advanced topics will ensure that even experienced Spring users will find information to help them use
Spring effectively. You will probably want to keep this book on your desk for reference as you develop
applications using Spring.


Aims of This Book
This book covers all major parts of the Spring framework, explaining the framework's functionality and
motivation. It aims to equip you to implement advanced applications using Spring.


What This Book Covers
This book covers most of the feature set of Spring 1.2.
You will learn:
What Spring offers. Spring has a large feature set: We guide you through the features and show how

they form a coherent whole.
Why Spring does what it does. We discuss the motivation behind many Spring features and the
rationale for Spring's approach.
When to use Spring features, and about best practices when using Spring.
We cover the following areas of Spring, with the background discussion necessary to put the Spring
functionality in context:
The core Inversion of Control container and the concept of Dependency Injection that underpins it.
Spring's lightweight container provides sophisticated configuration management, and a flexible
backbone within which other services can be used.
Spring's Aspect-Oriented Programming (AOP) framework and why AOP is important in J2EE
development. Together with Spring's Dependency Injection capabilities, Spring AOP enables a POJO
programming model, in which application code has minimal dependencies on Spring APIs, even when
it enjoys Spring services.
Spring's approach to service abstraction, and the goals it achieves.
Transaction management: Core concepts, Spring's programmatic and declarative transaction
management services, and how to use them effectively.
Data access using Spring: You'll see how Spring provides a sophisticated, consistent abstraction over
a variety of popular data access technologies. We'll look in detail at how to access data using Spring's
JDBC functionality, iBATIS SQL Maps, and the Hibernate O/R mapping framework. You will gain a
solid conceptual understanding of Spring data access that is applicable to other supported
persistence APIs such as TopLink.
Spring's MVC web framework. Three chapters provide in-depth information about the motivation for
Spring's MVC framework, how it compares with other popular web application frameworks such as
Struts, and how to use it in scenarios from basic to advanced. You will also see how to use Spring
MVC to generate custom content types.
Spring services for exposing and accessing remote services. Spring provides a unique remoting
framework that works over a variety of protocols, but is entirely POJO-based.
Spring services for accessing and implementing EJBs.
Spring services relating to JMS.
Spring's integration with the open source Quartz scheduler and other popular open source and

commercial products.
How Spring can be used in the design and implementation of a complete application, through our
sample application.
Effective testing strategies for Spring applications. One of the major advantages of a sophisticated
Dependency Injection container is that it can enable effective unit testing of application code; Spring
goes a step further by providing powerful integration testing features that also don't require a
container, significantly increasing the speed of develop-test cycles.
Throughout, we discuss best practices. Sophisticated frameworks such as Spring inevitably allow multiple
ways to achieve the same end; we try to provide guidance as to how to make the best choice.


We also help you understand how Spring can provide a basis for a clean, layered architecture, and how
appropriate use of Spring facilitates good OO design and architectural practice.


Assumed Knowledge
This book assumes a working knowledge of core features such as JDBC. Chapters related to J2EE topics
such as EJB and JMS assume a basic grounding in those areas. However, we provide suggestions on
further reading at appropriate points, so don't worry too much now if you're not sure your knowledge is
deep enough.
We assume sound knowledge of OO design and Java language features including reflection, inner
classes, and dynamic proxies.
Existing Spring Framework knowledge is not required.
We assume a basic knowledge of SQL and relational database concepts. An understanding of object
relational mapping (ORM) is helpful but not essential.
If you've used a MVC web framework such as Struts, you will probably grasp the web content more
quickly. However, we begin our coverage of Spring MVC with a discussion of the concepts behind MVC
web frameworks.

Recommended Reading
Throughout the book we recommend further reading that will help you get a deeper grasp of concepts
important to Spring development, such as Aspect-Oriented programming (AOP).
You may find it helpful to read J2EE without EJB (Johnson/Hoeller, Wrox, 2004), which provides a detailed
discussion of the architectural rationale for lightweight containers such as Spring. However, this book is not
purely a sequel to that book and can be understood entirely on its own.
There are many Spring Framework resources online. You should find the following particularly helpful:
The Spring Home page (www.springframework.org): Portal for most Spring-related information,
including the reference documentation and downloads.
Spring Forums (forum.springframework.org): The place to go to ask questions about Spring. The
Spring community is generally very welcoming and helpful.


What You Need to Use This Book
To run the sample application and examples, you will need:
The Spring Framework version 1.2 or later.
A J2EE web container or/and application server. We used Tomcat 5 where only a web container was
required, and WebLogic 8.1 where an application server was required. However, Spring is designed
for portability between application servers, and we also tested our code on other products. Thus you
do not need to use any particular server product; you can use whatever product you are most familiar
and comfortable with.
A relational database and appropriate JDBC drivers. You should be able to modify our DDL fairly
easily to work with the database of your choice.
The Hibernate O/R mapping framework, version 3.0, available from www.hibernate.org.
Various third-party libraries, including Jakarta Commons Logging. The necessary JAR files are
included with the full Spring distribution; see documentation with Spring for details.
The JUnit testing tool, ideally integrated with your IDE.
The popular Jakarta Ant build tool.
All this software is open source or free for developer use.
We recommend a good Java IDE with refactoring support, such as Eclipse or IntelliJ IDEA. Such tools

either ship with or can easily be integrated with validating XML editors that provide code assistance. These
are helpful when editing Spring XML bean definition documents and other XML artifacts such as Hibernate
mapping files, iBATIS SQL Maps definition files, and J2EE deployment descriptors. You should never
need to edit XML content purely by hand.


The Sample Application
The sample application for this book is an online ticketing application: a web application that works against
a relational database. This application uses JSPs to generate web content; Spring's MVC web framework
to implement the web tier; Spring to configure middle tier objects and make them transactional; and a mix
of Hibernate and JDBC to access and update relational data. We use Spring's data access abstraction to
conceal use of Hibernate behind a portable layer of data access interfaces. We have tested with a choice
of popular relational databases including MySQL and Oracle.
This application can run in either a web container or on an application server, using either local or global
transaction management.
The requirements for the sample application are discussed in Appendix A; the implementation is discussed
in Chapter 15.
This problem domain was first used for the sample application in Expert One-on-One J2EE Design and
Development. It has been rewritten for this book to bring it up to date with the current Spring feature set
and current views on best practice for J2EE applications using Spring. If you have the earlier book, you
should find the comparison interesting. The past two to three years have seen many developments in the
Java framework space, so best practice has moved on significantly (not merely concerning Spring itself).


Conventions
To help you get the most from the text and keep track of what's happening, we've used a number of
conventions throughout the book.
Note Tips, hints, tricks, and asides to the current discussion are offset and placed in italics like this.
As for styles in the text:
We italicize important words when we introduce them.

We show keyboard strokes like this: Ctrl+A.
We show filenames, URLs, and code within the text like so: persistence.properties
We present code in two different ways:
In code examples we highlight new and important code with a gray background.
The gray highlighting is not used for code that's less important in the present
context, or has been shown before.


Source Code
As you work through the examples in this book, you may choose either to type in all the code manually or
to use the source code files that accompany the book. All of the source code used in this book is available
for download at www.wrox.com. Once at the site, simply locate the book's title (either by using the Search
box or by using one of the title lists) and click the Download Code link on the book's detail page to obtain
all the source code for the book.
Because many books have similar titles, you may find it easiest to search by ISBN; this book's ISBN
is 0-7645-7483-3.
Once you download the code, just decompress it with your favorite compression tool. Alternatively, go to
the main Wrox code download page at www.wrox.com/dynamic/books/download.aspx to see the
code available for this book and all other Wrox books.


Errata
We make every effort to ensure that there are no errors in the text or in the code. However, no one is
perfect, and mistakes do occur. If you find an error in one of our books, like a spelling mistake or faulty
piece of code, we would be very grateful for your feedback. By sending in errata, you may save another
reader hours of frustration and at the same time help us provide even higher quality information.
To find the errata page for this book, go to www.wrox.com and locate the title using the Search box or
one of the title lists. Then, on the book details page, click the Book Errata link. On this page you can view
all errata that has been submitted for this book and posted by Wrox editors. A complete book list including
links to each book's errata is also available at www.wrox.com/misc-pages/booklist.shtml.

If you don't spot "your" error on the Book Errata page, go to
www.wrox.com/contact/techsupport.shtml and complete the form there to send us the error you
have found. We'll check the information and, if appropriate, post a message to the book's errata page and
fix the problem in subsequent editions of the book.


p2p.wrox.com
For author and peer discussion, join the P2P forums at p2p.wrox.com. The forums are a Web-based
system for you to post messages relating to Wrox books and related technologies and interact with other
readers and technology users. The forums offer a subscription feature to email you topics of interest of
your choosing when new posts are made to the forums. Wrox authors, editors, other industry experts, and
your fellow readers are present on these forums.
At you will find a number of different forums that will help you not only as you
read this book but also as you develop your own applications. To join the forums, just follow these steps:
1. Go to p2p.wrox.com and click the Register link.
2. Read the terms of use and click Agree.
3. Complete the required information to join as well as any optional information you wish to provide and
click Submit.
4. You will receive an email with information describing how to verify your account and complete the
joining process.
You can read messages in the forums without joining P2P, but in order to post your own messages,
you must join.
Once you join, you can post new messages and respond to messages other users post. You can read
messages at any time on the Web. If you would like to have new messages from a particular forum
emailed to you, click the Subscribe to this Forum icon by the forum name in the forum listing.
For more information about how to use the Wrox P2P, be sure to read the P2P FAQs for answers to
questions about how the forum software works as well as many common questions specific to P2P and
Wrox books. To read the FAQs, click the FAQ link on any P2P.

Chapter 1: Introducing the Spring Framework
Why Spring?
The Spring Framework is an open source application framework that aims to make J2EE development
easier. In this chapter we'll look at the motivation for Spring, its goals, and how Spring can help you
develop high-quality applications quickly.
Important

Spring is an application framework. Unlike single-tier frameworks such as Struts or
Hibernate, Spring aims to help structure whole applications in a consistent, productive
manner, pulling together best-of-breed single-tier frameworks to create a coherent
architecture.

Problems with the Traditional Approach to J2EE
Since the widespread implementation of J2EE applications in 1999/2000, J2EE has not been an
unqualified success in practice. While it has brought a welcome standardization to core middle- tier
concepts such as transaction management, many — perhaps most — J2EE applications are overcomplex, take excessive effort to develop, and exhibit disappointing performance. While Spring is
applicable in a wide range of environments — not just server-side J2EE applications — the original
motivation for Spring was the J2EE environment, and Spring offers many valuable services for use in J2EE
applications.
Experience has highlighted specific causes of complexity and other problems in J2EE applications. (Of
course, not all of these problems are unique to J2EE!) In particular:
J2EE applications tend to contain excessive amounts of "plumbing" code. In the many code
reviews we've done as consultants, time and time again we see a high proportion of code that doesn't
do anything: JNDI lookup code, Transfer Objects, try/catch blocks to acquire and release JDBC
resources. . . . Writing and maintaining such plumbing code proves a major drain on resources that
should be focused on the application's business domain.
Many J2EE applications use a distributed object model where this is inappropriate. This is one
of the major causes of excessive code and code duplication. It's also conceptually wrong in many
cases; internally distributed applications are more complex than co-located applications, and often
much less performant. Of course, if your business requirements dictate a distributed architecture, you

need to implement a distributed architecture and accept the tradeoff that incurs (and Spring offers
features to help in such scenarios). But you shouldn't do so without a compelling reason.
The EJB component model is unduly complex. EJB was conceived as a way of reducing
complexity when implementing business logic in J2EE applications; it has not succeeded in this aim in
practice.
EJB is overused. EJB was essentially designed for internally distributed, transactional applications.
While nearly all non-trivial applications are transactional, distribution should not be built into the basic
component model.
Many "J2EE design patterns" are not, in fact, design patterns, but workarounds for technology
limitations. Overuse of distribution, and use of complex APIs such as EJB, have generated many
questionable design patterns; it's important to examine these critically and look for simpler, more
productive, approaches.
J2EE applications are hard to unit test. The J2EE APIs, and especially, the EJB component model,
were defined before the agile movement took off. Thus their design does not take into account ease of
unit testing. Through both APIs and implicit contracts, it is surprisingly difficult to test applications
based on EJB and many other J2EE APIs outside an application server. Yet unit testing outside an
application server is essential to achieve high test coverage and to reproduce many failure scenarios,
such as loss of connectivity to a database. It is also vital to ensuring that tests can be run quickly
during the development or maintenance process, minimizing unproductive time waiting for


redeployment.
Certain J2EE technologies have simply failed. The main offender here is entity beans, which have
proven little short of disastrous for productivity and in their constraints on object orientation.
The traditional response to these problems has been to wait for tool support to catch up with the J2EE
specifications, meaning that developers don't need to wrestle with the complexity noted above. However,
this has largely failed. Tools based on code generation approaches have not delivered the desired
benefits, and have exhibited a number of problems of their own. In this approach, we might generate all
those verbose JNDI lookups, Transfer Objects, and try/catch blocks.
In general, experience has shown that frameworks are better than tool-enabled code generation. A good

framework is usually much more flexible at runtime than generated code; it should be possible to configure
the behavior of one piece of code in the framework, rather than change many generated classes. Code
generation also poses problems for round-tripping in many cases. A well-conceived framework can also
offer a coherent abstraction, whereas code generation is typically just a shortcut that fails to conceal
underlying complexities during the whole project lifecycle. (Often complexities will re-emerge damagingly
during maintenance and troubleshooting.)
A framework-based approach recognizes the fact that there is a missing piece in the J2EE jigsaw: the
application developer's view. Much of what J2EE provides, such as JNDI, is simply too low level to be a
daily part of programmer's activities. In fact, the J2EE specifications and APIs can be judged as far more
successful, if one takes the view that they do not offer the developer a programming model so much as
provide a solid basis on which that programming model should sit. Good frameworks supply this missing
piece and give application developers a simple, productive, abstraction, without sacrificing the core
capability of the platform.
Important Using J2EE "out of the box" is not an attractive option. Many J2EE APIs and services are
cumbersome to use. J2EE does a great job of standardizing low-level infrastructure,
solving such problems as how can Java code access transaction management without
dealing with the details of XA transactions. But J2EE does not provide an easily usable
view for application code.
That is the role of an application framework, such as Spring.
Recognizing the importance of frameworks to successful J2EE projects, many developers and companies
have attempted to write their own frameworks, with varying degrees of success. In a minority of cases, the
frameworks achieved their desired goals and significantly cut costs and improved productivity. In most
cases, however, the cost of developing and maintaining a framework itself became an issue, and
framework design flaws emerged. As the core problems are generic, it's much preferable to work with a
single, widely used (and tested) framework, rather than implement one in house. No matter how large an
organization, it will be impossible to achieve a degree of experience matching that available for a product
that is widely used in many companies. If the framework is open source, there's an added advantage in
that it's possible to contribute new features and enhancements that may be adopted. (Of course it's
possible to contribute suggestions to commercial products, but it's typically harder to influence successful
commercial products, and without the source code it's difficult to make equally useful contributions.) Thus,

increasingly, generic frameworks such as Struts and Hibernate have come to replace in-house frameworks
in specific areas.
The Spring Framework grew out of this experience of using J2EE without frameworks, or with a mix of inhouse frameworks. However, unlike Struts, Hibernate, and most other frameworks, Spring offers services
for use throughout an application, not merely in a single architectural tier. Spring aims to take away much
of the pain resulting from the issues in the list we've seen, by simplifying the programming model, rather
than concealing complexity behind a complex layer of tools.
Important

Spring enables you to enjoy the key benefits of J2EE, while minimizing the complexity
encountered by application code.
The essence of Spring is in providing enterprise services to Plain Old Java Objects
(POJOs). This is particularly valuable in a J2EE environment, but application code
delivered as POJOs is naturally reusable in a variety of runtime environments.


Lightweight Frameworks
Some parts of J2EE can properly be termed frameworks themselves. Among them, EJB amounts to a
framework because it provides a structure for application code, and defines a consistent way of accessing
services from the application server. However, the EJB framework is cumbersome to use and restrictive.
The work involved in implementing an EJB is excessive, given that the architects of J2EE expected that all
business logic in J2EE applications would be implemented in EJBs. Developers must cope with three to
four Java classes for each EJB; two verbose deployment descriptors for each EJB JAR file; and excessive
amounts of code for client access to EJBs and EJB access to their environment. The EJB component
model, up to and including EJB 2.1, fails to deliver on many of its goals, and fails to deliver a workable
structure for business logic in J2EE applications. The EJB Expert Group has finally realized this and is
attempting an overhaul of the EJB model in EJB 3.0, but we need a solution, right now, and Spring already
demonstrates a far superior one in most cases.
Not merely EJB, but the majority of frameworks in the early years of J2EE, proved to have problems of
their own. For example, Apache Avalon offered powerful configuration management and other services,
but never achieved widespread adoption, partly because of the learning curve it required, and because

application code needed to be aware of Avalon APIs.
Important A framework can only be as good as the programming model it provides. If a framework
imposes too many requirements on code using it, it creates lock-in and — even more
important — constrains developers in ways that may not be appropriate. The application
developer, rather than framework designer, often has a better understanding of how code
should be written.
Yet a framework should provide guidance with respect to good practice: It should make the
right thing easy to do. Getting the right mixture of constraint and freedom is the key
challenge of framework design, which is as much art as science.
Given this history, the emergence of a number of lightweight frameworks was inevitable. These aim to
provide many of the services of "out of the box" J2EE in a simpler, more manageable manner. They aim to
do their best to make the framework itself invisible, while encouraging good practice. Above all, they aim to
enable developers to work primarily with POJOs, rather than special objects such as EJBs.
As the name implies, lightweight frameworks not only aim to reduce complexity in application code, but
avoid unnecessary complexity in their own functioning. So a lightweight framework won't have a high
startup time, won't involve huge binary dependencies, will run in any environment, and won't place
obstacles in the way of testing.
While "old J2EE" was characterized by high complexity and a welter of questionable "design patterns" to
give it intellectual respectability, lightweight J2EE is about trying to find the "simplest thing that can possibly
work": wise advice from the XP methodology, regardless of whether you embrace XP practices overall.
Important

While all the lightweight frameworks grew out of J2EE experience, it's important to note
that none of them is J2EE-specific. A lightweight container can be used in a variety of
environments: even in applets.
For example, the Spring Rich Client project demonstrates the value of the Spring model
outside the server environment, in rich client applications.

Enter Spring
Spring is both the most popular and most ambitious of the lightweight frameworks. It is the only one to

address all architectural tiers of a typical J2EE application, and the only one to offer a comprehensive
range of services, as well as a lightweight container. We'll look at Spring's modules in more detail later, but
the following are the key Spring modules:
Inversion of Control container: The core "container" Spring provides, enabling sophisticated
configuration management for POJOs. The Spring IoC container can manage fine or coarse- grained
POJOs (object granularity is a matter for developers, not the framework), and work with other parts of
Spring to offer services as well as configuration management. We'll explain IoC and Dependency
Injection later in this chapter.


Aspect-Oriented Programming (AOP) framework: AOP enables behavior that would otherwise be
scattered through different methods to be modularized in a single place. Spring uses AOP under the
hood to deliver important out-of-the-box services such as declarative transaction management. Spring
AOP can also be used to implement custom code that would otherwise be scattered between
application classes.
Data access abstraction: Spring encourages a consistent architectural approach to data access,
and provides a unique and powerful abstraction to implement it. Spring provides a rich hierarchy of
data access exceptions, independent of any particular persistence product. It also provides a range of
helper services for leading persistence APIs, enabling developers to write persistence
framework–agnostic data access interfaces and implement them with the tool of their choice.
JDBC simplification: Spring provides an abstraction layer over JDBC that is significantly simpler and
less error-prone to use than JDBC when you need to use SQL-based access to relational databases.
Transaction management: Spring provides a transaction abstraction that can sit over JTA "global"
transactions (managed by an application server) or "local" transactions using the JDBC, Hibernate,
JDO, or another data access API. This abstraction provides a consistent programming model in a
wide range of environments and is the basis for Spring's declarative and programmatic transaction
management.
MVC web framework: Spring provides a request-based MVC web framework. Its use of shared
instances of multithreaded "controllers" is similar to the approach of Struts, but Spring's web
framework is more flexible, and integrates seamlessly with the Spring IoC container. All other Spring

features can also be used with other web frameworks such as Struts or JSF.
Simplification for working with JNDI, JTA, and other J2EE APIs: Spring can help remove the
need for much of the verbose, boilerplate code that "doesn't do anything." With Spring, you can
continue to use JNDI or EJB, if you want, but you'll never need to write another JNDI lookup. Instead,
simple configuration can result in Spring performing the lookup on your behalf, guaranteeing that
resources such as JNDI contexts are closed even in the event of an exception. The dividend is that
you get to focus on writing code that you need to write because it relates to your business domain.
Lightweight remoting: Spring provides support for POJO-based remoting over a range of protocols,
including RMI, IIOP, and Hessian, Burlap, and other web services protocols.
JMS support: Spring provides support for sending and receiving JMS messages in a much simpler
way than provided through standard J2EE.
JMX support: Spring supports JMX management of application objects it configures.
Support for a comprehensive testing strategy for application developers: Spring not only helps
to facilitate good design, allowing effective unit testing, but provides a comprehensive solution for
integration testing outside an application server.


Spring's Values
To make the most effective use of Spring, it's important to understand the motivation behind it. Spring
partly owes its success to its being based on a clear vision, and remaining true to that vision as its scope
has expanded.
The key Spring values can be summarized as follows:
Spring is a non-invasive framework. This is the key departure from most previous frameworks.
Whereas traditional frameworks such as EJB or Apache Avalon force application code to be aware of
the framework, implementing framework-specific interfaces or extending framework- specific classes,
Spring aims to minimize the dependence of application code on the framework. Thus Spring can
configure application objects that don't import Spring APIs; it can even be used to configure many
legacy classes that were written without any knowledge of Spring. This has many benefits. For
example:
Application code written as part of a Spring application can be run without Spring or any other

container.
Lock-in to Spring is minimized. For example, you could migrate to another lightweight container,
or possibly even reuse application objects in an EJB 3.0 EJB container, which supports a subset
of Spring's Dependency Injection capability.
Migration to future versions of Spring is easier. The less your code depends on the framework,
the greater the decoupling between the implementation of your application and that of the
framework. Thus the implementation of Spring can change significantly without breaking your
code, allowing the framework to be improved while preserving backward compatibility.
Of course in some areas, such as the web framework, it's impossible to avoid application code
depending on the framework. But Spring consistently attempts to reach the non-invasive ideal
where configuration management is concerned.
Spring provides a consistent programming model, usable in any environment. Many web
applications simply don't need to run on expensive, high-end, application servers, but are better off
running on a web container such as Tomcat or Jetty. It's also important to remember that not all
applications are server-side applications. Spring provides a programming model that insulates
application code from environment details such as JNDI, making code less dependent on its runtime
context.
Spring aims to promote code reuse. Spring helps to avoid the need to make some important hard
decisions up front, like whether your application will ever use JTA or JNDI; Spring abstractions will
allow you to deploy your code in a different environment if you ever need to. Thus Spring enables you
to defer architectural choices, potentially delivering benefits such as the need to purchase an
application server license only when you know exactly what your platform requirements are, following
tests of throughput and scalability.
Spring aims to facilitate Object Oriented design in J2EE applications. You might be asking "How
can a J2EE application, written in Java — an OO language — not be OO?" In reality, many J2EE
applications do not deserve the name of OO applications. Spring aims to remove some of the
impediments in place of OO in traditional designs. As one of the reviewers on this book commented,
"The code I've seen from my team in the year since we adopted Spring has consistently been better
factored, more coherent, loosely coupled and reusable."
Spring aims to facilitate good programming practice, such as programming to interfaces,

rather than classes. Use of an IoC container such as Spring greatly reduces the complexity of coding
to interfaces, rather than classes, by elegantly concealing the specification of the desired
implementation class and satisfying its configuration requirements. Callers using the object through its
interface are shielded from this detail, which may change as the application evolves.
Spring promotes pluggability. Spring encourages you to think of application objects as named
services. Ideally, the dependencies between such services are expressed in terms of interfaces. Thus


you can swap one service for another without impacting the rest of your application. The way in which
each service is configured is concealed from the client view of that service.
Spring facilitates the extraction of configuration values from Java code into XML or properties
files. While some configuration values may be validly coded in Java, all nontrivial applications need
some configuration externalized from Java source code, to allow its management without
recompilation or Java coding skills. (For example, if there is a timeout property on a particular object, it
should be possible to alter its value without being a Java programmer.) Spring encourages developers
to externalize configuration that might otherwise have been inappropriately hard-coded in Java source
code. More configurable code is typically more maintainable and reusable.
Spring is designed so that applications using it are as easy as possible to test. As far as
possible, application objects will be POJOs, and POJOs are easy to test; dependence on Spring APIs
will normally be in the form of interfaces that are easy to stub or mock. Unlike the case of JNDI, for
example, stubbing or mocking is easy; unlike the case of Struts, for example, application classes are
seldom forced to extend framework classes that themselves have complex dependencies.
Spring is consistent. Both in different runtime environments and different parts of the framework,
Spring uses a consistent approach. Once you learn one part of the framework, you'll find that that
knowledge can be leveraged in many others.
Spring promotes architectural choice. While Spring provides an architectural backbone, Spring
aims to facilitate replaceability of each layer. For example, with a Spring middle tier, you should be
able to switch from one O/R mapping framework to another with minimal impact on business logic
code, or switch from, say, Struts to Spring MVC or WebWork with no impact on the middle tier.
Spring does not reinvent the wheel. Despite its broad scope, Spring does not introduce its own

solution in areas such as O/R mapping where there are already good solutions. Similarly, it does not
implement its own logging abstraction, connection pool, distributed transaction coordinator, remoting
protocols, or other system services that are already well-served in other products or application
servers. However, Spring does make these existing solutions significantly easier to use, and places
them in a consistent architectural approach.
We'll examine these values later in this chapter and throughout this book. Many of these values are also
followed by other lightweight frameworks. What makes Spring unique is that it provides such a consistent
approach to delivering on them, and provides a wide enough range of services to be helpful throughout
typical applications.