THIRD EDITION

covers Spring 3.0

THIRD EDITION

Craig Walls

Praise for Spring in Action

This is an excellent book. It is very well written. Examples are very concise and easy to follow.

—Sunil Parikh, DZone

5 out of 5 stars ... a great instructive book.

—Nicola Pedot, Java User Group Trento

You will learn how to use Spring to write simpler, easier-to-maintain code so that you can focus on what really matters—your critical business needs.

—Springframework.org

Encyclopedic and eminently readable. Five stars all around!

—JavaLobby.org

Superbly organized and fluently written.

—Internet Bookwatch

Easy to read … with just enough humor mixed in.

—Books-On-Line

A rare book.

—Computing Reviews

Best overall introduction to Spring.

—Taruvai Subramaniam, Amazon reader

“Really pushes Spring into Action.”

—Patrick Steger, Zühlke Engineering

“Tremendous focus and fun to read ... zooms in on things developers need to know.”

—Doug Warren, Java Web Services

Spring in Action

T ^HIRD E ^DITION

CRAIG WALLS

M A N N I N G

SHELTER ISLAND

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity.

For more information, please contact Special Sales Department Manning Publications Co.

20 Baldwin Road PO Box 261

Shelter Island, NY 11964 Email: [email protected]

©2011 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning

Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end.

Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine.

Manning Publications Co. Development editors: Sebastian Stirling 20 Baldwin Road Copyeditor: Benjamin Berg PO Box 261 Proofreader: Katie Tennant Shelter Island, NY 11964 Typesetter: Dottie Marsico

Cover designer: Marija Tudor

ISBN 9781935182351

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 – MAL – 16 15 14 13 12 11

v

brief contents

P

1 C

S

...1

1 ^■ Springing into action 3 2 ^■ Wiring beans 30

3 ^■ Minimizing XML configuration in Spring 64 4 ^■ Aspect-oriented Spring 84

P

2 S

... 111

5 ^■ Hitting the database 113 6 ^■ Managing transactions 146

7 ■ Building web applications with Spring MVC 164 8 ^■ Working with Spring Web Flow 199

9 ^■ Securing Spring 224

P

3 I

S

... 253

10 ■ Working with remote services 255 11 ^■ Giving Spring some REST 277 12 ^■ Messaging in Spring 310

13 ^■ Managing Spring beans with JMX 333 14 ^■ Odds and ends 350

vii

contents

preface xv

acknowledgments xvii about this book xix

about the cover illustration xxiii

P ^ART 1 C ^ORE S ^PRING ...1

1 Springing into action 3

1.1 Simplifying Java development 4

Unleashing the power of POJOs 5 ^■ Injecting dependencies 6 Applying aspects 10 ^■ Eliminating boilerplate code with templates 15

1.2 Containing your beans 17

Working with an application context 18 ^■ A bean’s life 19 1.3 Surveying the Spring landscape 20

Spring modules 20 ^■ The Spring portfolio 23 1.4 What’s new in Spring 27

What’s new in Spring 2.5? 27 ^■ What’s new in Spring 3.0? 28 What’s new in the Spring portfolio? 28

1.5 Summary 29

CONTENTS

viii

2 Wiring beans 30

2.1 Declaring beans 31

Setting up Spring configuration 32 ^■ Declaring a simple bean 33 ^■ Injecting through constructors 34 ^■ Bean scoping 38 ^■ Initializing and destroying beans 39 2.2 Injecting into bean properties 41

Injecting simple values 42 ^■ Referencing other beans 43 Wiring properties with Spring’s p namespace 46 ^■ Wiring collections 47 ^■ Wiring nothing (null) 52

2.3 Wiring with expressions 52

Expressing SpEL fundamentals 53 ^■ Performing operations on SpEL values 56 ^■ Sifting through collections in SpEL 59 2.4 Summary 63

3 Minimizing XML configuration in Spring 64

3.1 Automatically wiring bean properties 65

The four kinds of autowiring 65 ^■ Default autowiring 68 Mixing auto with explicit wiring 69

3.2 Wiring with annotations 70

Using @Autowired 71 ^■ Applying standards-based autowiring with @Inject 74 ^■ Using expressions with annotation

injection 76

3.3 Automatically discovering beans 77 Annotating beans for autodiscovery 78 Filtering component-scans 79

3.4 Using Spring’s Java-based configuration 80 Setting up for Java-based configuration 80 ^■ Defining a configuration class 81 ^■ Declaring a simple bean 81 Injecting with Spring’s Java-based configuration 82 3.5 Summary 83

4 Aspect-oriented Spring 84

4.1 What’s aspect-oriented programming? 85

Defining AOP terminology 86 ^■ Spring’s AOP support 88 4.2 Selecting join points with pointcuts 91

Writing pointcuts 92 ^■ Using Spring’s bean() designator 93

CONTENTS ix

4.3 Declaring aspects in XML 93

Declaring before and after advice 95 ^■ Declaring around advice 97 ^■ Passing parameters to advice 98 ^■ Introducing new functionality with aspects 100

4.4 Annotating aspects 102

Annotating around advice 104 ^■ Passing arguments to annotated advice 105 ^■ Annotating introductions 106 4.5 Injecting AspectJ aspects 107

4.6 Summary 110

P ART 2 S PRING APPLICATION ESSENTIALS ...111

5 Hitting the database 113

5.1 Learning Spring’s data access philosophy 114 Getting to know Spring’s data access exception hierarchy 115 Templating data access 117 ^■ Using DAO support classes 119

5.2 Configuring a data source 121

Using JNDI data sources 121 ^■ Using a pooled data source 122 ^■ JDBC driver-based data source 123 5.3 Using JDBC with Spring 124

Tackling runaway JDBC code 124 ^■ Working with JDBC templates 127

5.4 Integrating Hibernate with Spring 132

A Hibernate overview 134 ^■ Declaring a Hibernate session factory 134 ^■ Building Spring-free Hibernate 137 5.5 Spring and the Java Persistence API 138

Configuring an entity manager factory 139 ^■ Writing a JPA-based DAO 143

5.6 Summary 144

6 Managing transactions 146

6.1 Understanding transactions 147

Explaining transactions in only four words 148

Understanding Spring’s transaction management support 149

CONTENTS

x

6.2 Choosing a transaction manager 150

JDBC transactions 151 ^■ Hibernate transactions 151 ^■ Java Persistence API transactions 152 ^■ Java transaction API transactions 153

6.3 Programming transactions in Spring 153 6.4 Declaring transactions 155

Defining transaction attributes 156 ^■ Declaring transactions in XML 160 ^■ Defining annotation-driven transactions 162 6.5 Summary 163

7 Building web applications with Spring MVC 164

7.1 Getting started with Spring MVC 165

Following a request through Spring MVC 165 ^■ Setting up Spring MVC 167

7.2 Writing a basic controller 169

Configuring an annotation-driven Spring MVC 170 ^■ Defining the home page controller 170 ^■ Resolving views 173 ^■ Defining the home page view 177 ^■ Rounding out the Spring application context 179 7.3 Handling controller input 181

Writing a controller that processes input 181 ^■ Rendering the view 183

7.4 Processing forms 185

Displaying the registration form 185 ^■ Processing form input 187 ^■ Validating input 189

7.5 Handling file uploads 193

Adding a file upload field to the form 193 ^■ Receiving uploaded files 194 ^■ Configuring Spring for file uploads 197

7.6 Summary 197

8 Working with Spring Web Flow 199

8.1 Installing Spring Web Flow 200 Configuring Web Flow in Spring 200 8.2 The components of a flow 203

States 203 ^■ Transitions 206 ^■ Flow data 207 8.3 Putting it all together: the pizza flow 209

Defining the base flow 209 ^■ Collecting customer information 213 ^■ Building an order 218 ^■ Taking payment 221

CONTENTS xi

8.4 Securing web flows 222 8.5 Summary 223

9 Securing Spring 224

9.1 Introducing Spring Security 225

Getting started with Spring Security 226 ^■ Using the Spring Security configuration namespace 226 9.2 Securing web requests 227

Proxying servlet filters 228 ^■ Configuring minimal web security 228 ^■ Intercepting requests 232

9.3 Securing view-level elements 235

Accessing authentication details 235 ^■ Rendering with authorities 236

9.4 Authenticating users 238

Configuring an in-memory user repository 239

Authenticating against a database 240 ^■ Authenticating against LDAP 241 ^■ Enabling remember-me functionality 245 9.5 Securing methods 246

Securing methods with @Secured 246 ^■ Using JSR-250’s

@RolesAllowed 247 ^■ Pre-/Post-invocation security with SpEL 247 ^■ Declaring method-level security pointcuts 252 9.6 Summary 252

P ^ART 3 I ^NTEGRATING S ^PRING ...253

10 Working with remote services 255

10.1 An overview of Spring remoting 256 10.2 Working with RMI 258

Exporting an RMI service 259 ^■ Wiring an RMI service 261

10.3 Exposing remote services with Hessian and Burlap 263 Exposing bean functionality with Hessian/Burlap 264

Accessing Hessian/Burlap services 266 10.4 Using Spring’s HttpInvoker 268

Exposing beans as HTTP services 268 ^■ Accessing services via HTTP 269

CONTENTS

xii

10.5 Publishing and consuming web services 270 Creating Spring-enabled JAX-WS endpoints 271 Proxying JAX-WS services on the client side 274 10.6 Summary 276

11 Giving Spring some REST 277

11.1 Getting REST 278

The fundamentals of REST 278 ^■ How Spring supports REST 279

11.2 Writing resource-oriented controllers 279

Dissecting a RESTless controller 280 ^■ Handling RESTful URLs 281 ^■ Performing the REST verbs 284

11.3 Representing resources 287

Negotiating resource representation 288 ^■ Working with HTTP message converters 291

11.4 Writing REST clients 294

Exploring RestTemplate’s operations 295 ^■ GETting resources 296 ^■ PUTting resources 299 ^■ DELETE-ing resources 301 ^■ POSTing resource data 301 ^■ Exchanging resources 304

11.5 Submitting RESTful forms 306

Rendering hidden method fields in JSP 306 ^■ Unmasking the real request 307

11.6 Summary 309

12 Messaging in Spring 310

12.1 A brief introduction to JMS 311

Architecting JMS 312 ^■ Assessing the benefits of JMS 314 12.2 Setting up a message broker in Spring 316

Creating a connection factory 316 ^■ Declaring an ActiveMQ message destination 317

12.3 Using Spring’s JMS template 318

Tackling runaway JMS code 318 ^■ Working with JMS templates 319

12.4 Creating message-driven POJOs 325

Creating a message listener 326 ^■ Configuring message listeners 327

CONTENTS xiii

12.5 Using message-based RPC 327

Working with Spring message-based RPC 328 ^■ Asynchronous RPC with Lingo 330

12.6 Summary 332

13 Managing Spring beans with JMX 333

13.1 Exporting Spring beans as MBeans 334

Exposing methods by name 337 ^■ Using interfaces to define MBean operations and attributes 339 ^■ Working with annotation-driven MBeans 340 ^■ Handing MBean collisions 342

13.2 Remoting MBeans 343

Exposing remote MBeans 343 ^■ Accessing remote MBeans 344 Proxying MBeans 345

13.3 Handling notifications 346 Listening for notifications 348 13.4 Summary 349

14 Odds and ends 350

14.1 Externalizing configuration 351

Replacing property placeholders 352 ^■ Overriding properties 354 ^■ Encrypting external properties 355 14.2 Wiring JNDI objects 357

Working with conventional JNDI 357 ^■ Injecting JNDI objects 359 ^■ Wiring EJBs in Spring 362

14.3 Sending email 363

Configuring a mail sender 363 ^■ Constructing the email 365 14.4 Scheduling and background tasks 370

Declaring scheduled methods 371 ^■ Declaring asynchronous methods 373

14.5 Summary 374 14.6 The end...? 374

index 377

xv

preface

Wow! As I write this, it’s been almost seven years since Spring 1.0 was released and Ryan Breidenbach and I started work on the first edition of Spring in Action. Back then, who would have guessed that Spring would transform Java development as much as it has?

In that first edition, Ryan and I tried to cover every corner of the Spring Frame- work. For the most part, we were successful. Back then the entire Spring story could easily be told in 11 chapters with dependency injection, AOP, persistence, transactions, Spring MVC, and Acegi Security as the main characters. Of course, back then that story had to be told with a lot of XML. (Does anybody remember what it was like declaring transactions with TransactionProxyFactoryBean?)

By the time I got around to writing the second edition, Spring had grown quite a bit. Again, I tried to squeeze everything I could into a single book. I found out it wasn’t possible. Spring had expanded well beyond what could be discussed in a 700- to 800-page book. In fact, entire, completely written chapters were cut out of the second edition because there wasn’t room.

More than three years and two major versions of Spring have passed since the sec- ond edition was printed. Spring covers more ground than ever before and it would take several volumes to comprehensively cover the entire Spring portfolio. It’s not possible to cram everything there is to know about Spring into a single book.

So I’m not going to even try.

Often books get thicker with each successive edition. But you’ve probably noticed by now that this third edition of Spring in Action has fewer pages than the second edi- tion. That’s possible for a couple of reasons.

PREFACE

xvi

Since I couldn’t fit everything into one volume, I was choosy about what topics made it into this edition. I decided to focus on what I believe are the core Spring top- ics that most Spring developers should know. That’s not to say that the other topics aren’t important, but these are the essentials of Spring development.

The other reason this edition is smaller is due to the fact that while Spring’s reach has continued to expand, it has continued to become simpler with each release.

Spring’s rich set of configuration namespaces, adoption of annotation-driven pro- gramming models, and application of sensible conventions and defaults have reduced Spring configuration from page upon page of XML down to only a handful of elements.

But make no mistake: though there are fewer pages, I’ve still managed to pack a lot of new Spring goodness into them. Along with the dependency injection, AOP, and declarative transactions Spring has long provided, here’s a sampling of the stuff you’ll learn in this edition that’s new or changed since the second edition:

■ Annotation-based bean wiring that dramatically reduces the amount of Spring XML configuration

■ A new expression language for evaluating values wired into bean properties dynamically at runtime

■ Spring’s all-new annotation-driven Spring MVC framework, which is far more flexible than the former hierarchical controller framework

■ Securing Spring applications with Spring Security, much simpler now with a new configuration namespace, convenient defaults, and support for expression- oriented security rules

■ First-class support for building and consuming REST resources, based on Spring MVC

Whether you’re new to Spring or a Spring veteran, I hope that you’ll find this book to be an indispensable guide as you use Spring in your projects.

xvii

acknowledgments

Before you put your hands on this book, it was touched by many other hands—hands that edited it, reviewed it, proofread it, and managed the whole publishing process.

You wouldn’t be reading this book if it weren’t for all those hands.

First, I’d like to thank everyone at Manning for working hard, pressuring me to get this darn thing done, and for doing their part to make sure that this book is the best it could be: Marjan Bace, Michael Stephens, Christina Rudloff, Karen Tegtmeyer, Maureen Spencer, Mary Piergies, Sebastian Stirling, Benjamin Berg, Katie Tennant, Janet Vail, and Dottie Marsico.

Along the way, a handful of other people were given the opportunity to read the manuscript in its roughest form and provide feedback, telling me what I got right and (gasp) where I missed the mark. Many thanks to all of those reviewers for their valu- able feedback: Valentin Crettaz, Jeff Addison, John Ryan, Olivier Nouguier, Joshua White, Deiveehan Nallazhagappan, Adam Taft, Peter Pavlovich, Mykel Alvis, Rick Wagner, Patrick Steger, Josh Devins, Dan Alford, Alberto Lagna, Dan Dobrin, Robert Hanson, Chad Davis, Carol McDonald, Deepak Vohra, and Robert O’Connor. And a special thanks to Doug Warren for taking on the role of technical reviewer and going over the technical details of the book with a fine-toothed comb.

My gratitude is also due to those who played no direct part in producing the book, but were there providing support, friendship, good conversation, and making sure that I had adequate breaks from writing to do other things.

First and foremost, thanks to my wife Raymie. You’re my best friend, the love of my life, and the reason for everything I do. I love you very much. Thank you for putting up with another writing project and for supporting me.

ACKNOWLEDGMENTS

xviii

To Maisy and Madi, my little princesses, thank you for your hugs, laughs, imagina- tion, and the occasional Mario Kart breaks.

To my colleagues at SpringSource, thank you for continuing to revolutionize how we develop software and for giving me the opportunity to be a part of what you do.

Special thanks to the two SpringSourcers I work with every day, Keith Donald and Roy Clarkson—we’ve done some awesome stuff in the past year and I look forward to the amazing things that lie ahead.

Many thanks to my No Fluff/Just Stuff cohorts for reminding me every few week- ends that I’m not nearly as smart as you guys: Ted Neward, Venkat Subramaniam, Tim Berglund, Matthew McCullough, Matt Stine, Brian Goetz, Jeff Brown, Dave Klein, Ken Sipe, Nathaniel Schutta, Neal Ford, Pratik Patel, Rohit Bhardwaj, Scott Davis, Mark Richards, and of course, Jay Zimmerman.

Finally, there are many other folks out there that I’d like to send a shout out to for their part in shaping me, my career, and this book: Ryan Breidenbach, Ben Rady, Mike Nash, Matt Smith, John Woodward, Greg Vaughn, Barry Rogers, Paul Holser, Derek Lane, Erik Weibust, and Andrew Rubalcaba.

xix

about this book

The Spring Framework was created with a very specific goal in mind—to make devel- oping Java EE applications easier. Along the same lines, Spring in Action, Third Edition was written to make learning how to use Spring easier. My goal is not to give you a blow-by-blow listing of Spring APIs. Instead, I hope to present the Spring Framework in a way that is most relevant to a Java EE developer by providing practical code exam- ples from real-world experiences. Since Spring is a modular framework, this book was written in the same way. I recognize that not all developers have the same needs. Some may want to learn the Spring Framework from the ground up, while others may want to pick and choose different topics and go at their own pace. That way, the book can act as a tool for learning Spring for the first time as well as a guide and reference for those wanting to dig deeper into specific features.

Who should read this book

Spring in Action, Third Edition, is for all Java developers, but enterprise Java developers will find it particularly useful. While I will guide you along gently through code exam- ples that build in complexity throughout each chapter, the true power of Spring lies in its ability to make enterprise applications easier to develop. Therefore, enterprise developers will most fully appreciate the examples presented in this book.

Because a vast portion of Spring is devoted to providing enterprise services, many parallels can be drawn between Spring and EJB. Therefore, any experience you have will be useful in making comparisons between these two frameworks. A portion of this book is dedicated to this topic. In fact, the final five chapters demonstrate how Spring

ABOUTTHISBOOK

xx

can support enterprise integration of web applications. If you are an enterprise appli- cation developer, you will find the last part of this book especially valuable.

Roadmap

Spring in Action, Third Edition, is divided into three parts. The first part introduces you to the essentials of the Spring Framework. Part 2 goes beyond that by delving into the common elements of a Spring application. The final part shows how Spring can be used to integrate with other applications and services.

In part 1, you’ll explore dependency injection (DI) and aspect-oriented program- ming (AOP), two essential features of the Spring Framework. This will give you a good understanding of Spring’s fundamentals that will be utilized throughout the book.

In chapter 1, you’ll be introduced to DI and AOP and how they lend themselves to developing loosely coupled Java applications.

Chapter 2 takes a more detailed look at how to configure and associate your appli- cation objects using dependency injection. You’ll learn how to write loosely coupled components and wire their dependencies and properties within the Spring container using XML.

Once you have the basics of Spring XML configuration down, chapter 3 will pres- ent annotation-oriented alternatives to XML configuration.

Chapter 4 explores how to use Spring’s AOP to decouple cross-cutting concerns from the objects that they service. This chapter also sets the stage for later chapters, where you’ll use Spring AOP to provide declarative services such as transactions, secu- rity, and caching.

Part 2 builds on the DI and AOP features introduced in part 1, and shows you how to apply these concepts to build the common elements of an application.

Chapter 5 covers Spring’s support for data persistence. You’ll be introduced to Spring’s JDBC support, which helps you remove much of the boilerplate code associ- ated with JDBC. You’ll also see how Spring integrates with persistence frameworks such as Hibernate and the Java Persistence API (JPA).

Chapter 6 complements chapter 5, showing you how to ensure integrity in your database using Spring’s transaction support. You’ll see how Spring uses AOP to give simple application objects the power of declarative transactions.

Chapter 7 introduces you to Spring’s MVC web framework. You’ll discover how Spring can transparently bind web parameters to your business objects and provide validation and error handling at the same time. You’ll also see how easy it is to add functionality to your web applications using Spring MVC controllers.

Chapter 8 explores Spring Web Flow, an extension to Spring MVC that enables development of conversational web applications. In this chapter you’ll learn how to build web applications that guide the user through a specific flow.

In chapter 9 you’ll learn how to apply security to your application using Spring Security. You’ll see how Spring Security secures applications both at the web request level using servlet filters and at the method level using Spring AOP.

ABOUTTHISBOOK xxi

After building an application with what you’ve learned from part 2, you may want to integrate it with other applications or services. In part 3 you’ll learn how to do that.

Chapter 10 explores how to expose your application objects as remote services.

You’ll also learn how to seamlessly access remote services as though they were any other object in your application. Remoting technologies explored will include RMI, Hessian/Burlap, SOAP-based web services, and Spring’s own HttpInvoker.

Chapter 11 revisits Spring MVC, showing how to use it to expose your application data as RESTful resources. In addition, you’ll learn how to develop REST clients with Spring’s RestTemplate.

Chapter 12 looks at using Spring to send and receive asynchronous messages with JMS. In addition to basic JMS operations with Spring, you’ll also learn how to use the open source Lingo project to expose and consume asynchronous remote services over JMS.

Chapter 13 will show you how to use Spring to schedule jobs, send emails, access JNDI-configured resources, and manage your application objects with JMX.

Wrapping up our exploration of Spring, chapter 14 will show you how to use Spring to schedule jobs, send emails, and access JNDI-configured resources.

Code conventions

There are many code examples throughout this book. These examples will always appear in a fixed-width code font. If there is a part of an example I want you to pay extra attention to, it will appear in a bolded code font. Any class name, method name or XML fragment within the normal text of the book will appear in code font as well.

Many of Spring’s classes and packages have exceptionally long (but expressive) names. Because of this, line-continuation markers (➥) may be included when necessary.

Not all code examples in this book will be complete. Often I only show a method or two from a class to focus on a particular topic. Complete source code for the appli- cations found throughout the book can be downloaded from the publisher’s website at www.manning.com/SpringinActionThirdEdition.

About the author

Craig Walls is a software developer with more than 13 years of experience and is the coauthor of XDoclet in Action (Manning, 2003) and two earlier editions of Spring in Action (Manning, 2005 and 2007). He’s a zealous promoter of the Spring Framework, speaking frequently at local user groups and conferences and writing about Spring on his blog. When he’s not slinging code, Craig spends as much time as he can with his wife, two daughters, six birds, four dogs, two cats, and an ever-fluctuating number of tropical fish. Craig lives in Plano, Texas.

Author Online

Purchase of Spring in Action, Third Edition includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask

ABOUTTHISBOOK

xxii

technical questions, and receive help from the author and from other users. To access the forum and subscribe to it, point your web browser to www.manning.com/

SpringinActionThirdEdition. This page provides information on how to get on the forum once you are registered, what kind of help is available, and the rules of con- duct on the forum.

Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the book’s forum remains voluntary (and unpaid).

We suggest you try asking the author some challenging questions, lest his interest stray!

The Author Online forum and the archives of previous discussions will be accessi- ble from the publisher’s website as long as the book is in print.

About the title

By combining introductions, overviews, and how-to examples, the In Action books are designed to help learning and remembering. According to research in cognitive sci- ence, the things people remember are things they discover during self-motivated exploration.

Although no one at Manning is a cognitive scientist, we are convinced that for learning to become permanent it must pass through stages of exploration, play, and, interestingly, retelling of what is being learned. People understand and remember new things, which is to say they master them, only after actively exploring them.

Humans learn in action. An essential part of an In Action guide is that it is example- driven. It encourages the reader to try things out, to play with new code, and explore new ideas.

There is another, more mundane, reason for the title of this book: our readers are busy. They use books to do a job or to solve a problem. They need books that allow them to jump in and jump out easily and learn just what they want just when they want it. They need books that aid them in action. The books in this series are designed for such readers.

xxiii

about the cover illustration

The figure on the cover of Spring in Action, Third Edition, is a “Le Caraco,” or an inhab- itant of the province of Karak in southwest Jordan. Its capital is the city of Al-Karak, which boasts an ancient hilltop castle with magnificent views of the Dead Sea and sur- rounding plains.

The illustration is taken from a French travel book, Encyclopédie des Voyages by J. G.

St. Sauveur, published in 1796. Travel for pleasure was a relatively new phenomenon at the time and travel guides such as this one were popular, introducing both the tour- ist as well as the armchair traveler to the inhabitants of other regions of France and abroad.

The diversity of the drawings in the Encyclopédie des Voyages speaks vividly of the uniqueness and individuality of the world’s towns and provinces just 200 years ago.

This was a time when the dress codes of two regions separated by a few dozen miles identified people uniquely as belonging to one or the other. The travel guide brings to life a sense of isolation and distance of that period and of every other historic period except our own hyperkinetic present.

Dress codes have changed since then and the diversity by region, so rich at the time, has faded away. It is now often hard to tell the inhabitant of one continent from another. Perhaps, trying to view it optimistically, we have traded a cultural and visual diversity for a more varied personal life. Or a more varied and interesting intellectual and technical life.

We at Manning celebrate the inventiveness, the initiative, and the fun of the com- puter business with book covers based on the rich diversity of regional life two centu- ries ago brought back to life by the pictures from this travel guide.

Part 1 Core Spring

S

In chapter 2, “Wiring beans,” we’ll dive deeper into how to use Spring’s XML- based configuration to keep application objects loosely coupled with depen- dency injection. You’ll learn how to define application objects and then wire them with their dependencies.

XML isn’t the only way that Spring can be configured. Picking up where the previous chapter left off, chapter 3, “Minimizing XML configuration in Spring,”

explores some new features in Spring that make it possible to wire application objects with minimal or (in some cases, no) XML.

Chapter 4, “Aspect-oriented Spring,” explores how to use Spring’s AOP fea- tures to decouple systemwide services (such as security and auditing) from the objects they service. This chapter sets the stage for chapters 6 and 9, where you’ll learn how to use Spring AOP to provide declarative transaction and security.

3

Springing into action

It all started with a bean.

In 1996, the Java programming language was still a young, exciting, up-and- coming platform. Many developers flocked to the language because they’d seen how to create rich and dynamic web applications using applets. They soon learned that there was more to this strange new language than animated juggling cartoon characters. Unlike any language before it, Java made it possible to write complex applications made up of discrete parts. They came for the applets, but they stayed for the components.

In December of that year, Sun Microsystems published the JavaBeans 1.00-A spec- ification. JavaBeans defined a software component model for Java. This specification defined a set of coding policies that enabled simple Java objects to be reusable and easily composed into more complex applications. Although JavaBeans were intended as a general-purpose means of defining reusable application components,

This chapter covers

 Exploring Spring’s core modules

 Decoupling application objects

 Managing cross-cutting concerns with AOP

 Spring’s bean container

4 ^{CHAPTER 1} Springing into action

they were primarily used as a model for building user interface widgets. They seemed too simple to be capable of any “real” work. Enterprise developers wanted more.

Sophisticated applications often require services such as transaction support, secu- rity, and distributed computing—services not directly provided by the JavaBeans spec- ification. So in March 1998, Sun published version 1.0 of the Enterprise JavaBeans (EJB) specification. This specification extended the notion of Java components to the server side, providing much-needed enterprise services, but failed to continue the simplicity of the original JavaBeans specification. Except in name, EJB bears little resemblance to the original JavaBeans specification.

Despite the fact that many successful applications have been built based on EJB, EJB never achieved its intended purpose: to simplify enterprise application develop- ment. It’s true that EJB’s declarative programming model simplifies many infrastruc- tural aspects of development, such as transactions and security. But in a different way, EJBs complicate development by mandating deployment descriptors and plumbing code (home and remote/local interfaces). Over time, many developers became disen- chanted with EJB. As a result, its popularity has waned in recent years, leaving many developers looking for an easier way.

Today, Java component development has returned to its roots. New programming techniques, including aspect-oriented programming (AOP) and dependency injection (DI), are giving JavaBeans much of the power previously reserved for EJBs. These tech- niques furnish plain-old Java objects (POJOs) with a declarative programming model reminiscent of EJB, but without all of EJB’s complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice.

In fairness, even EJBs have evolved to promote a POJO-based programming model.

Employing ideas such as DI and AOP, the latest EJB specification is significantly sim- pler than its predecessors. But for many developers, this move is too little, too late. By the time the EJB 3 specification had entered the scene, other POJO-based develop- ment frameworks had already established themselves as de facto standards in the Java community.

Leading the charge for lightweight POJO-based development is the Spring Frame- work, which we’ll explore throughout this book. In this chapter, we’ll explore the Spring Framework at a high level, giving you a taste of what Spring is about. This chap- ter will give you a good idea of the types of problems Spring solves, and will set the stage for the rest of the book. First things first—let’s find out what Spring is all about.

1.1 Simplifying Java development

Spring is an open source framework, originally created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development. Spring was created to address the complexity of enterprise application development, and makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. But Spring’s usefulness isn’t limited to server-side development. Any Java applica- tion can benefit from Spring in terms of simplicity, testability, and loose coupling.

5 Simplifying Java development

A BEAN BY ANY OTHER NAME... Although Spring uses the words bean and JavaBean liberally when referring to application components, this doesn’t mean that a Spring component must follow the JavaBeans specification to the letter. A Spring component can be any type of POJO. In this book, I assume the loose definition of JavaBean, which is synonymous with POJO. As you’ll see throughout this book, Spring does many things. But at the root of almost everything Spring provides are a few foundational ideas, all focused on Spring’s fun- damental mission: Spring simplifies Java development.

That’s a bold statement! A lot of frameworks claim to simplify something or other.

But Spring aims to simplify the broad subject of Java development. This begs for more explanation. How does Spring simplify Java development?

To back up its attack on Java complexity, Spring employs four key strategies:

 Lightweight and minimally invasive development with plain old Java objects (POJOs)

 Loose coupling through dependency injection and interface orientation

 Declarative programming through aspects and common conventions

 Boilerplate reduction through aspects and templates

Almost everything Spring does can be traced back to one or more of these four strate- gies. Throughout the rest of this chapter, I’ll expand on each of these ideas, showing concrete examples of how Spring makes good on its promise to simplify Java develop- ment. Let’s start with seeing how Spring remains minimally invasive by encouraging POJO-oriented development.

1.1.1 Unleashing the power of POJOs

If you’ve been doing Java development for long, you’ve probably seen (and may have even worked with) frameworks that lock you in by forcing you to extend one of their classes or implement one of their interfaces. The classic example is that of an EJB2–era stateless session bean. As you can see from this trivial HelloWorldBean, the EJB 2 spec- ification made some rather heavy demands:

package com.habuma.ejb.session;

import javax.ejb.SessionBean;

import javax.ejb.SessionContext;

public class HelloWorldBean implements SessionBean { public void ejbActivate() {

}

public void ejbPassivate() { }

public void ejbRemove() { }

Listing 1.1 EJB 2.1 forced you to implement methods that weren’t needed.

Why are these methods needed?

6 ^{CHAPTER 1} Springing into action

public void setSessionContext(SessionContext ctx) { }

public String sayHello() { return "Hello World";

}

public void ejbCreate() { }

}

The SessionBean interface would let you hook into the EJB’s lifecycle by implement- ing several lifecycle callback methods (those methods that start with ejb). Or I should rephrase that to say that the SessionBean interface would force you to hook into the EJB’s lifecycle, even if you didn’t need to. The bulk of the code in HelloWorldBean is there solely for the sake of the framework. This raises the question: who’s working for whom?

EJB 2 wasn’t alone when it came to being invasive. Other popular frameworks such as the earlier versions of Struts, WebWork, and Tapestry imposed themselves upon otherwise simple Java classes. These heavyweight frameworks forced developers to write classes that were littered with unnecessary code, locked into their framework, and were often difficult to write tests against.

Spring avoids (as much as possible) littering your application code with its API. Spring almost never forces you to implement a Spring-specific interface or extend a Spring-specific class. Instead, the classes in a Spring-based application often have no indication that they’re being used by Spring. At worst, a class may be annotated with one of Spring’s annotations, but is otherwise a POJO.

To illustrate, if the HelloWorldBean class shown in listing 1.1 were to be rewritten to function as a Spring managed bean, it might look like this.

package com.habuma.spring;

public class HelloWorldBean { public String sayHello() {

return "Hello World";

} }

Isn’t that better? Gone are all of those noisy lifecycle methods. HelloWorldBean doesn’t implement, extend, or even import anything from the Spring API. Hello- WorldBean is lean, mean, and in every sense of the phrase, a plain-old Java object.

Despite their simple form, POJOs can be powerful. One of the ways Spring empow- ers POJOs is by assembling them using dependency injection. Let’s see how depen- dency injection can help keep application objects decoupled from each other.

1.1.2 Injecting dependencies

The phrase dependency injection may sound intimidating, conjuring up notions of a complex programming technique or design pattern. But as it turns out, DI isn’t nearly

Listing 1.2 Spring doesn’t make any unreasonable demands on HelloWorldBean.

EJB core business logic

This is all you needed

7 Simplifying Java development

as complex as it sounds. By applying DI in your projects, you’ll find that your code will become significantly simpler, easier to understand, and easier to test.

Any nontrivial application (pretty much anything more complex than a Hello World example) is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally, each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). This can lead to highly coupled and hard-to-test code.

For example, consider the Knight class shown next.

package com.springinaction.knights;

public class DamselRescuingKnight implements Knight { private RescueDamselQuest quest;

public DamselRescuingKnight() { quest = new RescueDamselQuest();

}

public void embarkOnQuest() throws QuestException { quest.embark();

} }

As you can see, DamselRescuingKnight creates its own quest, a RescueDamselQuest, within the constructor. This makes a DamselRescuingKnight tightly coupled to a RescueDamselQuest and severely limits the knight’s quest-embarking repertoire. If a damsel needs rescuing, this knight’s there. But if a dragon needs slaying or a round table needs… well…rounding, then this knight’s going to have to sit it out.

What’s more, it’d be terribly difficult to write a unit test for DamselRescuing- Knight. In such a test, you’d like to be able to assert that the quest’s embark() method is called when the knight’s embarkOnQuest() is called. But there’s no clear way to accomplish that here. Unfortunately, DamselRescuingKnight will remain untested.

Coupling is a two-headed beast. On one hand, tightly coupled code is difficult to test, difficult to reuse, difficult to understand, and typically exhibits “whack-a-mole”

bug behavior (fixing one bug results in the creation of one or more new bugs). On the other hand, a certain amount of coupling is necessary—completely uncoupled code doesn’t do anything. In order to do anything useful, classes need to know about each other somehow. Coupling is necessary, but should be carefully managed.

With DI, on the other hand, objects are given their dependencies at creation time by some third party that coordinates each object in the system. Objects aren’t expected to create or obtain their dependencies—dependencies are injected into the objects that need them.

To illustrate this point, let’s look at BraveKnight in the following listing, a knight that’s not only brave, but is capable of embarking on any kind of quest that comes along.

Listing 1.3 A DamselRescuingKnight can only embark on RescueDamselQuests.

Tightly coupled to RescueDamselQuest

8 ^{CHAPTER 1} Springing into action

package com.springinaction.knights;

public class BraveKnight implements Knight { private Quest quest;

public BraveKnight(Quest quest) { this.quest = quest;

}

public void embarkOnQuest() throws QuestException { quest.embark();

} }

As you can see, unlike DamselRescuingKnight, BraveKnight doesn’t create his own quest. Instead, he’s given a quest at construction time as a constructor argument. This is a type of dependency injection known as constructor injection.

What’s more, the quest he’s given is typed as Quest, an interface that all quests implement. So BraveKnight could embark on a RescueDamselQuest, a SlayDragon- Quest, a MakeRoundTableRounderQuest, or any other Quest implementation he’s given.

The point here is that BraveKnight isn’t coupled to any specific implementation of Quest. It doesn’t matter to him what kind of quest he’s asked to embark upon, so long as it implements the Quest interface. That’s the key benefit of DI—loose coupling. If an object only knows about its dependencies by their interface (not by their implemen- tation or how they’re instantiated), then the dependency can be swapped out with a different implementation without the depending object knowing the difference.

One of the most common ways that a dependency will be swapped out is with a mock implementation during testing. You were unable to adequately test Damsel- RescuingKnight due to tight coupling, but you can easily test BraveKnight by giving it a mock implementation of Quest, as shown next.

package com.springinaction.knights;

import static org.mockito.Mockito.*;

import org.junit.Test;

public class BraveKnightTest {

@Test

public void knightShouldEmbarkOnQuest() throws QuestException { Quest mockQuest = mock(Quest.class);

BraveKnight knight = new BraveKnight(mockQuest);

knight.embarkOnQuest();

verify(mockQuest, times(1)).embark();

} }

Listing 1.4 A BraveKnight is flexible enough to take on any Quest he’s given

Listing 1.5 To test BraveKnight, you’ll inject it with a mock Quest.

Quest is injected

Create mock Quest Inject mock Quest

9 Simplifying Java development

Here you’re using a mock object framework known as Mockito to create a mock implementation of the Quest interface. With the mock object in hand, you create a new instance of BraveKnight, injecting the mock Quest via the constructor. After calling the embarkOnQuest() method, you ask Mockito to ver- ify that the mock Quest’s embark() method was called exactly once.

INJECTING A QUEST INTO A KNIGHT

Now that your BraveKnight class is written in such a way that you can give him any quest you want, how can you specify which Quest to give him?

The act of creating associations between appli- cation components is commonly referred to as wir-

ing. In Spring, there are many ways to wire components together, but a common approach has always been via XML. The following listing shows a simple Spring config- uration file, knights.xml, that gives a BraveKnight a SlayDragonQuest.

<?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-3.0.xsd">

<bean id="knight" class="com.springinaction.knights.BraveKnight">

<constructor-arg ref="quest" />

</bean>

<bean id="quest"

class="com.springinaction.knights.SlayDragonQuest" />

</beans>

This is a simple approach to wiring beans in Spring. Don’t concern yourself too much with the details right now. We’ll dig more into Spring configuration and see what’s going on when we get to chapter 2. We’ll also look at other ways that we can wire beans in Spring.

Now that you’ve declared the relationship between BraveKnight and a Quest, you need to load up the XML configuration file and kick off the application.

SEEING IT WORK

In a Spring application, an application context loads bean definitions and wires them together. The Spring application context is fully responsible for the creation of and wiring of the objects that make up the application. Spring comes with several imple- mentations of its application context, each primarily differing only in how they load their configuration.

Listing 1.6 Injecting a SlayDragonQuest into a BraveKnight with Spring

Inject quest bean

Create SlayDragonQuest

Figure 1.1 Dependency injection involves giving an object its

dependencies as opposed to an object having to acquire those dependencies on its own.

10 ^{CHAPTER 1} Springing into action

Because the beans in knights.xml are declared in an XML file, an appropriate choice for application context might be ClassPathXmlApplicationContext. This Spring context implementation loads the Spring context from one or more XML files located in the application’s classpath. The main() method in the following listing uses ClassPathXmlApplicationContext to load knights.xml and to get a reference to the Knight object.

package com.springinaction.knights;

import org.springframework.context.ApplicationContext;

import org.springframework.context.support.ClassPathXmlApplicationContext;

public class KnightMain {

public static void main(String[] args) { ApplicationContext context =

new ClassPathXmlApplicationContext("knights.xml");

Knight knight = (Knight) context.getBean("knight");

knight.embarkOnQuest();

} }

Here the main() method creates the Spring application context based on the knights.xml file. Then it uses the application context as a factory to retrieve the bean whose ID is knight. With a reference to the Knight object, it calls the embarkOnQuest() method to have the knight embark on the quest that it was given. Note that this class knows nothing about which type of Quest our hero has. For that matter, it’s blissfully unaware of the fact that it’s dealing with BraveKnight. Only the knights.xml file knows for sure what the implementations are.

And with that you have a quick introduction to dependency injection. You’ll see a lot more DI throughout this book. But if you want even more dependency injection, I encourage you to have a look at Dhanji R. Prasanna’s Dependency Injection, which cov- ers DI in fine detail.

But now let’s have a look at another of Spring’s Java-simplifying strategies: declara- tive programming through aspects.

1.1.3 Applying aspects

Although DI makes it possible to tie software components together loosely, aspect- oriented programming enables you to capture functionality that’s used throughout your application in reusable components.

Aspect-oriented programming is often defined as a technique that promotes sepa- ration of concerns within a software system. Systems are composed of several compo- nents, each responsible for a specific piece of functionality. Often these components also carry additional responsibility beyond their core functionality. System services such as logging, transaction management, and security often find their way into

Listing 1.7 KnightMain.java loads the Spring context containing a knight.

Load Spring context Get knight Use knight bean

11 Simplifying Java development

components whose core responsibility is something else. These system services are commonly referred to as cross-cutting concerns because they tend to cut across multiple components in a system.

By spreading these concerns across multiple components, you introduce two levels of complexity to your code:

 The code that implements the systemwide concerns is duplicated across multi- ple components. This means that if you need to change how those concerns work, you’ll need to visit multiple components. Even if you’ve abstracted the concern to a separate module so that the impact to your components is a single method call, that method call is duplicated in multiple places.

 Your components are littered with code that isn’t aligned with their core func- tionality. A method to add an entry to an address book should only be con- cerned with how to add the address and not with whether it’s secure or transactional.

Figure 1.2 illustrates this complexity. The business objects on the left are too inti- mately involved with the system services. Not only does each object know that it’s being logged, secured, and involved in a transactional context, but also each object is responsible for performing those services for itself.

AOP makes it possible to modularize these services and then apply them declaratively to the components that they should affect. This results in components that are more cohesive and that focus on their own specific concerns, completely ignorant of any sys- tem services that may be involved. In short, aspects ensure that POJOs remain plain.

It may help to think of aspects as blankets that cover many components of an appli- cation, as illustrated in figure 1.3. At its core, an application consists of modules that implement business functionality. With AOP, you can then cover your core application with layers of functionality. These layers can be applied declaratively throughout your application in a flexible manner without your core application even knowing they

Course service

Billing service

Student service

Instructor service

Content service

Logging module

Security module

Transaction manager

Figure 1.2 Calls to systemwide concerns such as logging and security are often scattered about in modules where those concerns are not their primary concern.

12 ^{CHAPTER 1} Springing into action

exist. This is a powerful concept, as it keeps the security, transaction, and logging con- cerns from littering the application’s core business logic.

To demonstrate how aspects can be applied in Spring, let’s revisit the knight exam- ple, adding a basic Spring aspect to the mix.

AOP IN ACTION

Anyone who knows anything about knights only knows about them because their deeds were chronicled in song by the musically inclined storytellers known as min- strels. Let’s suppose that you want to record the comings and goings of your Brave- Knight using the services of a minstrel. The following shows the Minstrel class you might use.

package com.springinaction.knights;

public class Minstrel {

public void singBeforeQuest() {

System.out.println("Fa la la; The knight is so brave!");

}

public void singAfterQuest() { System.out.println(

"Tee hee he; The brave knight did embark on a quest!");

} }

As you can see, Minstrel is a simple class with two methods. The singBeforeQuest() method is intended to be invoked before a knight embarks on a quest, and the sing- AfterQuest() method should be invoked after the knight has completed a quest. It should be simple to work this into your code, so let’s make the appropriate tweaks to BraveKnight to use the Minstrel. The following listing shows a first attempt.

Listing 1.8 A Minstrel is a musically inclined logging system of medieval times

Transaction manager

Course service

Student service

Instructor service

Billing service Content service

Logging module Security module

Figure 1.3 Using AOP, systemwide concerns blanket the components that they impact.

This leaves the application components to focus on their specific business functionality.

Called before quest

Called after quest

13 Simplifying Java development

package com.springinaction.knights;

public class BraveKnight implements Knight { private Quest quest;

private Minstrel minstrel;

public BraveKnight(Quest quest, Minstrel minstrel) { this.quest = quest;

this.minstrel = minstrel;

}

public void embarkOnQuest() throws QuestException { minstrel.singBeforeQuest();

quest.embark();

minstrel.singAfterQuest();

} }

That should do the trick. But something doesn’t seem right here. Is it really within the knight’s range of concern to manage his minstrel? It seems to me that a minstrel should just do his job without the knight asking him to do so. After all, that’s the min- strel’s job—to sing about the knight’s endeavors. Why should the knight have to keep reminding the minstrel to do his job?

Furthermore, because the knight needs to know about the minstrel, you’re forced to inject the Minstrel into the BraveKnight. This not only complicates the Brave- Knight’s code, but also makes me wonder if you’d ever want a knight who didn’t have a minstrel. What if the Minstrel is null? Should we introduce some null-checking logic to cover that case?

Your simple BraveKnight class is starting to get more complicated and would become more so if you were to handle the nullMinstrel scenario. But using AOP, you can declare that the minstrel should sing about a knight’s quests and free the knight from having to deal with the Minstrel methods directly.

To turn Minstrel into an aspect, all you need to do is declare it as one in the Spring configuration file. Here’s the updated knights.xml file, revised to declare Minstrel as an aspect.

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:aop="http://www.springframework.org/schema/aop"

xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/aop

http://www.springframework.org/schema/aop/spring-aop-3.0.xsd">

<bean id="knight" class="com.springinaction.knights.BraveKnight">

<constructor-arg ref="quest" />

</bean>

Listing 1.9 A BraveKnight that must call Minstrel methods

Listing 1.10 Declaring the Minstrel as an aspect

Should knight manage its own Minstrel?