MANNING Craig Walls FOURTH EDITION covers Spring 4 Praise for the Third Edition of Spring in Action Continues to be the de-facto reference guide to Spring. Offers clear explanations of concepts with very good examples in an easy-to-read format. —Dan Dobrin, CIBC An indispensable guide to the large landscape of Spring. —Mykel Alvis, Automaton Online The one book you need on your desk when working with Spring. —Josh Devins, Nokia Covers both the fundamentals and the breadth of Spring. —Chad Davis, Blackdog Software, Inc. Using Spring is not difficult—but with this book it becomes much easier. —Alberto Lagna, Biznology One of my favorite technology books. Great content delivered by a great teacher. —Robert Hanson, Author of Manning’s GWT in Action The right dose of humor with a load of technical wisdom is the perfect mix for learning Spring. —Valentin Crettaz, Goomzee Tremendous focus—and fun to read. —Doug Warren, Java Web Services Craig’s witty examples make complex concepts easy to understand. —Dan Alford Spring in Action FOURTH EDITION CRAIG WALLS MANNING 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 761 Shelter Island, NY 11964 Email: orders@manning.com ©2015 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 editor: Cynthia Kane 20 Baldwin Road Copyeditor: Andy Carroll Shelter Island, NY 11964 Proofreader: Alyson Brener Typesetter: Dottie Marsico Cover designer: Marija Tudor ISBN 9781617291203 Printed in the United States of America 12345678910–EBM–191817161514 v brief contents PART 1CORE SPRING ...............................................................1 1 ■ Springing into action 3 2 ■ Wiring beans 32 3 ■ Advanced wiring 64 4 ■ Aspect-oriented Spring 97 PART 2SPRING ON THE WEB.................................................129 5 ■ Building Spring web applications 131 6 ■ Rendering web views 164 7 ■ Advanced Spring MVC 194 8 ■ Working with Spring Web Flow 219 9 ■ Securing web applications 244 PART 3SPRING IN THE BACK END ..........................................279 10 ■ Hitting the database with Spring and JDBC 281 11 ■ Persisting data with object-relational mapping 305 12 ■ Working with NoSQL databases 327 13 ■ Caching data 362 14 ■ Securing methods 379 BRIEF CONTENTSvi PART 4INTEGRATING SPRING................................................391 15 ■ Working with remote services 393 16 ■ Creating REST APIs with Spring MVC 416 17 ■ Messaging in Spring 452 18 ■ Messaging with WebSocket and STOMP 485 19 ■ Sending email with Spring 511 20 ■ Managing Spring beans with JMX 523 21 ■ Simplifying Spring development with Spring Boot 540 vii contents preface xvii acknowledgments xix about this book xxi PART 1CORE SPRING....................................................1 1 Springing into action 3 1.1 Simplifying Java development 4 Unleashing the power of POJOs 5 ■ Injecting dependencies 5 Applying aspects 11 ■ Eliminating boilerplate code with templates 16 1.2 Containing your beans 18 Working with an application context 19 ■ A bean’s life 20 1.3 Surveying the Spring landscape 21 Spring modules 22 ■ The Spring portfolio 24 1.4 What’s new in Spring 27 What was new in Spring 3.1? 27 ■ What was new in Spring 3.2? 28 ■ What’s new in Spring 4.0? 29 1.5 Summary 30 CONTENTSviii 2 Wiring beans 32 2.1 Exploring Spring’s configuration options 33 2.2 Automatically wiring beans 34 Creating discoverable beans 34 ■ Naming a component-scanned bean 38 ■ Setting a base package for component scanning 38 Annotating beans to be automatically wired 39 ■ Verifying automatic configuration 41 2.3 Wiring beans with Java 43 Creating a configuration class 43 ■ Declaring a simple bean 44 ■ Injecting with JavaConfig 45 2.4 Wiring beans with XML 46 Creating an XML configuration specification 47 ■ Declaring a simple 48 ■ Initializing a bean with constructor injection 49 ■ Setting properties 54 2.5 Importing and mixing configurations 59 Referencing XML configuration in JavaConfig 59 Referencing JavaConfig in XML configuration 61 2.6 Summary 63 3 Advanced wiring 64 3.1 Environments and profiles 64 Configuring profile beans 66 ■ Activating profiles 70 3.2 Conditional beans 72 3.3 Addressing ambiguity in autowiring 75 Designating a primary bean 76 ■ Qualifying autowired beans 77 3.4 Scoping beans 81 Working with request and session scope 82 ■ Declaring scoped proxies in XML 84 3.5 Runtime value injection 84 Injecting external values 85 ■ Wiring with the Spring Expression Language 89 3.6 Summary 95 4 Aspect-oriented Spring 97 4.1 What is aspect-oriented programming? 98 Defining AOP terminology 99 ■ Spring’s AOP support 101 CONTENTS ix 4.2 Selecting join points with pointcuts 103 Writing pointcuts 104 ■ Selecting beans in pointcuts 106 4.3 Creating annotated aspects 106 Defining an aspect 106 ■ Creating around advice 110 Handling parameters in advice 112 ■ Annotating introductions 115 4.4 Declaring aspects in XML 117 Declaring before and after advice 118 ■ Declaring around advice 121 ■ Passing parameters to advice 122 Introducing new functionality with aspects 124 4.5 Injecting AspectJ aspects 125 4.6 Summary 127 PART 2SPRING ON THE WEB .....................................129 5 Building Spring web applications 131 5.1 Getting started with Spring MVC 132 Following the life of a request 132 ■ Setting up Spring MVC 134 ■ Introducing the Spittr application 138 5.2 Writing a simple controller 139 Testing the controller 140 ■ Defining class-level request handling 142 ■ Passing model data to the view 143 5.3 Accepting request input 148 Taking query parameters 149 ■ Taking input via path parameters 151 5.4 Processing forms 154 Writing a form-handling controller 156 ■ Validating forms 159 5.5 Summary 162 6 Rendering web views 164 6.1 Understanding view resolution 164 6.2 Creating JSP views 167 Configuring a JSP-ready view resolver 167 ■ Using Spring’s JSP libraries 169 6.3 Defining a layout with Apache Tiles views 182 Configuring a Tiles view resolver 182 CONTENTSx 6.4 Working with Thymeleaf 187 Configuring a Thymeleaf view resolver 187 ■ Defining Thymeleaf templates 189 6.5 Summary 193 7 Advanced Spring MVC 194 7.1 Alternate Spring MVC configuration 195 Customizing DispatcherServlet configuration 195 Adding additional servlets and filters 196 ■ Declaring DispatcherServlet in web.xml 197 7.2 Processing multipart form data 200 Configuring a multipart resolver 201 ■ Handling multipart requests 205 7.3 Handling exceptions 208 Mapping exceptions to HTTP status codes 209 ■ Writing exception-handling methods 211 7.4 Advising controllers 212 7.5 Carrying data across redirect requests 213 Redirecting with URL templates 214 ■ Working with flash attributes 215 7.6 Summary 217 8 Working with Spring Web Flow 219 8.1 Configuring Web Flow in Spring 220 Wiring a flow executor 220 ■ Configuring a flow registry 221 ■ Handling flow requests 222 8.2 The components of a flow 222 States 223 ■ Transitions 226 ■ Flow data 227 8.3 Putting it all together: the pizza flow 229 Defining the base flow 229 ■ Collecting customer information 232 ■ Building an order 238 Taking payment 240 8.4 Securing web flows 242 8.5 Summary 242 9 Securing web applications 244 9.1 Getting started with Spring Security 245 Understanding Spring Security modules 246 ■ Filtering web requests 246 ■ Writing a simple security configuration 248 CONTENTS xi 9.2 Selecting user details services 250 Working with an in-memory user store 251 ■ Authenticating against database tables 252 ■ Applying LDAP-backed authentication 255 ■ Configuring a custom user service 259 9.3 Intercepting requests 260 Securing with Spring Expressions 263 ■ Enforcing channel security 264 ■ Preventing cross-site request forgery 265 9.4 Authenticating users 267 Adding a custom login page 268 ■ Enabling HTTP Basic authentication 269 ■ Enabling remember-me functionality 270 Logging out 270 9.5 Securing the view 271 Using Spring Security’s JSP tag library 272 ■ Working with Thymeleaf’s Spring Security dialect 275 9.6 Summary 277 PART 3SPRING IN THE BACK END...............................279 10 Hitting the database with Spring and JDBC 281 10.1 Learning Spring’s data-access philosophy 282 Getting to know Spring’s data-access exception hierarchy 283 Templating data access 286 10.2 Configuring a data source 288 Using JNDI data sources 288 ■ Using a pooled data source 289 Using JDBC driver-based data sources 291 ■ Using an embedded data source 292 ■ Using profiles to select a data source 293 10.3 Using JDBC with Spring 295 Tackling runaway JDBC code 296 ■ Working with JDBC templates 299 10.4 Summary 304 11 Persisting data with object-relational mapping 305 11.1 Integrating Hibernate with Spring 307 Declaring a Hibernate session factory 307 ■ Building Spring-free Hibernate 309 11.2 Spring and the Java Persistence API 311 Configuring an entity manager factory 311 ■ Writing a JPA-based repository 316 CONTENTSxii 11.3 Automatic JPA repositories with Spring Data 318 Defining query methods 320 ■ Declaring custom queries 323 Mixing in custom functionality 324 11.4 Summary 326 12 Working with NoSQL databases 327 12.1 Persisting documents with MongoDB 328 Enabling MongoDB 329 ■ Annotating model types for MongoDB persistence 332 ■ Accessing MongoDB with MongoTemplate 335 ■ Writing a MongoDB repository 337 12.2 Working with graph data in Neo4j 341 Configuring Spring Data Neo4j 342 ■ Annotating graph entities 344 ■ Working with Neo4jTemplate 348 Creating automatic Neo4j repositories 349 12.3 Working with key-value data in Redis 354 Connecting to Redis 354 ■ Working with RedisTemplate 355 Setting key and value serializers 359 12.4 Summary 360 13 Caching data 362 13.1 Enabling cache support 363 Configuring a cache manager 364 13.2 Annotating methods for caching 368 Populating the cache 369 ■ Removing cache entries 373 13.3 Declaring caching in XML 374 13.4 Summary 378 14 Securing methods 379 14.1 Securing methods with annotations 380 Restricting method access with @Secured 380 ■ Using JSR-250’s @RolesAllowed with Spring Security 382 14.2 Using expressions for method-level security 383 Expressing method access rules 383 ■ Filtering method inputs and outputs 385 14.3 Summary 390 CONTENTS xiii PART 4INTEGRATING SPRING....................................391 15 Working with remote services 393 15.1 An overview of Spring remoting 394 15.2 Working with RMI 396 Exporting an RMI service 397 ■ Wiring an RMI service 399 15.3 Exposing remote services with Hessian and Burlap 402 Exposing bean functionality with Hessian/Burlap 402 Accessing Hessian/Burlap services 405 15.4 Using Spring’s HttpInvoker 407 Exposing beans as HTTP services 407 ■ Accessing services via HTTP 408 15.5 Publishing and consuming web services 410 Creating Spring-enabled JAX-WS endpoints 410 Proxying JAX-WS services on the client side 413 15.6 Summary 415 16 Creating REST APIs with Spring MVC 416 16.1 Getting REST 417 The fundamentals of REST 417 ■ How Spring supports REST 418 16.2 Creating your first REST endpoint 419 Negotiating resource representation 421 ■ Working with HTTP message converters 426 16.3 Serving more than resources 432 Communicating errors to the client 432 ■ Setting headers in the response 436 16.4 Consuming REST resources 439 Exploring RestTemplate’s operations 440 ■ GETting resources 441 ■ Retrieving resources 442 ■ Extracting response metadata 443 ■ PUTting resources 444 DELETEing resources 445 ■ POSTing resource data 446 Receiving object responses from POST requests 446 Receiving a resource location after a POST request 448 Exchanging resources 448 16.5 Summary 450 CONTENTSxiv 17 Messaging in Spring 452 17.1 A brief introduction to asynchronous messaging 453 Sending messages 454 ■ Assessing the benefits of asynchronous messaging 456 17.2 Sending messages with JMS 458 Setting up a message broker in Spring 458 ■ Using Spring’s JMS template 460 ■ Creating message-driven POJOs 469 ■ Using message-based RPC 472 17.3 Messaging with AMQP 474 A brief introduction to AMQP 475 ■ Configuring Spring for AMQP messaging 477 ■ Sending messages with RabbitTemplate 479 ■ Receiving AMQP messages 482 17.4 Summary 484 18 Messaging with WebSocket and STOMP 485 18.1 Working with Spring’s low-level WebSocket API 486 18.2 Coping with a lack of WebSocket support 491 18.3 Working with STOMP messaging 493 Enabling STOMP messaging 495 ■ Handling STOMP messages from the client 498 ■ Sending messages to the client 501 18.4 Working with user-targeted messages 505 Working with user messages in a controller 505 Sending messages to a specific user 507 18.5 Handling message exceptions 508 18.6 Summary 509 19 Sending email with Spring 511 19.1 Configuring Spring to send email 512 Configuring a mail sender 512 ■ Wiring and using the mail sender 514 19.2 Constructing rich email messages 515 Adding attachments 515 ■ Sending email with rich content 516 19.3 Generating email with templates 517 Constructing email messages with Velocity 518 ■ Using Thymeleaf to create email messages 520 19.4 Summary 522 CONTENTS xv 20 Managing Spring beans with JMX 523 20.1 Exporting Spring beans as MBeans 524 Exposing methods by name 527 ■ Using interfaces to define MBean operations and attributes 529 ■ Working with annotation-driven MBeans 530 ■ Handling MBean collisions 532 20.2 Remoting MBeans 533 Exposing remote MBeans 533 ■ Accessing remote MBeans 534 Proxying MBeans 536 20.3 Handling notifications 537 Listening for notifications 538 20.4 Summary 539 21 Simplifying Spring development with Spring Boot 540 21.1 Introducing Spring Boot 541 Adding starter dependencies 541 ■ Autoconfiguration 546 The Spring Boot CLI 546 ■ The Actuator 547 21.2 Building an application with Spring Boot 547 Handling requests 550 ■ Creating the view 552 Adding static artifacts 554 ■ Persisting the data 555 Try it out 557 21.3 Going Groovy with the Spring Boot CLI 560 Writing a Groovy controller 560 ■ Persisting with a Groovy repository 563 ■ Running the Spring Boot CLI 564 21.4 Gaining application insight with the Actuator 565 21.5 Summary 568 index 570 xvii preface The best keeps getting better. More than a dozen years ago, Spring entered the Java development scene with the ambitious goal of simplifying enterprise Java develop- ment. It challenged the heavyweight programming models of the time with a simpler and lighter programming model based on plain old Java objects. Now, several years and many releases later, we see that Spring has had a tremen- dous impact on enterprise application development. It has become a de facto stan- dard framework for countless Java projects and has had an impact on the evolution of some of the specifications and frameworks that it originally set out to replace. It’d be hard to deny that the current Enterprise JavaBeans (EJB) specification may have turned out very differently had Spring not challenged earlier versions of the EJB spec. But Spring itself continues to evolve and improve upon itself, always seeking to make the difficult development tasks simpler and empower Java developers with inno- vative features. Where Spring had first set out to challenge the status quo, Spring now has leapt ahead and is paving trails in Java application development. Therefore, it’s time for an updated edition of this book to expose the current state of Spring. There’s so much that has happened in the past few years since the previous edition of this book; it’d be impossible to cover everything in a single edition. Never- theless, I still tried to pack this fourth edition of Spring in Action with as much as I could. Here are just a few of the exciting new things that have been added in this edition: ■ An emphasis on Java-based Spring configuration with Java configuration options available for almost every area of Spring development ■ Conditional configuration and profiles that make runtime decisions regarding what Spring configuration should be used or ignored PREFACExviii ■ Several enhancements and improvements to Spring MVC, especially with regard to creating REST services ■ Using Thymeleaf with Spring web applications as an alternative to JSP ■ Enabling Spring Security with Java-based configuration ■ Using Spring Data to automatically generate repository implementations at runtime for JPA, MongoDB, and Neo4j ■ Spring’s new declarative caching support ■ Asynchronous web messaging with WebSocket and STOMP ■ Spring Boot, a game-changing new approach to working with Spring If you’re a seasoned Spring veteran, you’ll find that these new elements will become valuable additions to your Spring toolkit. On the other hand, if you’re new to Spring, you’ve picked a good time to learn Spring, and this book will help you get started. This is, indeed, an exciting time to be working with Spring. It’s been a blast to develop with Spring and write about it during the past 12 years. I can’t wait to see what Spring does next! xix acknowledgments Before this book goes to press, before it is bound, before it is boxed, before it is shipped, and before you get your hands on it, there are many other hands that have touched it along the way. Even if you have an eBook copy that didn’t go through that process, there were numerous hands on the bits and bytes that you downloaded— hands that edited it, reviewed it, typeset it, and proofread it. If it weren’t for all of those hands, this book wouldn’t exist. First, a big thank you to everyone at Manning for working hard, for their patience when the writing wasn’t moving as fast as it should have, and for prodding me along to get it done: Marjan Bace, Michael Stephens, Cynthia Kane, Andy Carroll, Benjamin Berg, Alyson Brener, Dottie Marisco, Mary Piergies, Janet Vail, and many others behind the scenes. Getting feedback early and often is just as critical when writing a book as it is when developing software. While the pages of this book were still in a very rough form, there were several great reviewers who took the time to read the drafts and provide feedback that helped shape the final product. Thanks to the following: Bob Casazza, Chaoho Hsieh, Christophe Martini, Gregor Zurowski, James Wright, Jeelani Basha, Jens Richter, Jonathan Thoms, Josh Hart, Karen Christenson, Mario Arias, Michael Roberts, Paul Balogh, and Ricardo da Silva Lima. And special thanks to John Ryan for his thor- ough technical review of the manuscript shortly before it went into production. Of course, I want to thank my beautiful wife for enduring yet another writing proj- ect and for her encouragement along the way. I love you more than you could possibly ever know. ACKNOWLEDGMENTSxx To Maisy and Madi, the most awesome little girls in the world, thank you again for your hugs, laughs, and unusual insights into what should go into the book. To my colleagues on the Spring team, what can I say? You guys ROCK! I’m humbled and grateful for being a part of the organization that drives Spring forward. I never cease to be amazed at the never-ending awesomeness that you crank out. And many thanks to everyone I encounter as I travel the country speaking at user groups and No Fluff/Just Stuff conferences. Finally, thank you to the Phoenicians. You (and Epcot fans) know what you did. xxi 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, Fourth 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. Spring in Action, Fourth Edition is for all Java developers, but enterprise Java develop- ers will find it particularly useful. While I will guide you along gently through code examples that build in complexity throughout each chapter, the true power of Spring lies in its ability to make enterprise applications easier to develop. Therefore, enter- prise developers will most fully appreciate the examples presented in this book. Because a vast portion of Spring is devoted to providing enterprise services, many par- allels can be drawn between Spring and EJB. Roadmap Spring in Action, Fourth Edition is divided into four parts. The first part introduces you to the essentials of the Spring Framework. Part 2 expands on that by showing how to build web applications with Spring. Part 3 steps behind the front end and shows where ABOUT THIS BOOKxxii Spring fits in the back end of an application. The final part shows how Spring can be used to integrate with other applications and services. In part 1, you’ll explore the Spring container, dependency injection (DI), and aspect-oriented programming…the essentials of the Spring Framework. This will give you a foundation upon which the rest of the book will build. ■ In chapter 1, you’ll be given an overview of Spring, including some basic exam- ples of DI and AOP. You’ll also get an overview of the greater Spring ecosystem. ■ Chapter 2 goes into more detail with DI, showing you various ways that the com- ponents in your application (the “beans”) can be wired together. This includes wiring with XML, Java, and automatic wiring. ■ With the basics of bean wiring down, chapter 3 presents several advanced wiring techniques. You won’t need these techniques that often, but when you do need them this chapter will show you how to get the most power out of the Spring container. ■ Chapter 4 explores how to use Spring AOP to decouple cross-cutting concerns from the objects that they service. This chapter also sets the stage for later chap- ters where you’ll use AOP to provide declarative services such as transactions, security, and caching. In part 2 you’ll see how to use Spring to build web applications. ■ Chapter 5 covers the basics of working with Spring MVC, the foundational web framework in Spring. You’ll see how to write controllers to handle web requests and respond with model data. ■ Once a controller is finished with its work, the model data must be rendered using a view. Chapter 6 will explore various view technologies that can be used with Spring, including JSP, Apache Tiles, and Thymeleaf. ■ Chapter 7 goes beyond the basics of Spring MVC. In this chapter, you’ll learn how to customize Spring MVC configuration, handle multipart file uploads, deal with exceptions that may occur in a controller, and pass data between requests with flash attributes. ■ 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 lead the user through a specific, guided flow. ■ In chapter 9 you’ll learn how to apply security to the web layer of your applica- tion using Spring Security. Part 3 goes behind the front end of an application and looks at how data is processed and persisted. ■ Data persistence is first tackled in chapter 10 using Spring’s abstraction over JDBC to work with data stored in a relational database. ■ Chapter 11 takes on data persistence from another angle, using the Java Persis- tence API (JPA) to store data in a relational database. ABOUT THIS BOOK xxiii ■ Chapter 12 looks at how Spring works with non-relational databases, such as MongoDB and Neo4j. Regardless of where the data is stored, caching can help improve performance by not hitting the database any more than necessary. ■ Chapter 13 introduces you to Spring’s support for declarative caching. ■ Chapter 14 revisits Spring Security, showing how to use AOP to apply security at the method level. The final part looks at ways to integrate your Spring applications with other systems. ■ Chapter 15 looks at how to create and consume remote services, including RMI, Hessian, Burlap, and SOAP-based services. ■ In chapter 16, Spring MVC is revisited to see how to create RESTful services using the same programming model as described previously in chapter 5. ■ Chapter 17 explores Spring support for asynchronous messaging. This chapter includes working with Java Message Service (JMS) as well as the Advanced Mes- sage Queuing Protocol (AMQP). ■ Asynchronous messaging takes a different twist in chapter 18 where you’ll see how to use Spring with WebSocket and STOMP for asynchronous communica- tion between the server and a client. ■ Chapter 19 looks at how to send emails with Spring. ■ Chapter 20 highlights Spring’s management support for Java Management Extensions (JMX), enabling you to monitor and modify runtime settings for a Spring application. ■ Finally, in chapter 21 you’ll be introduced to a game-changing and very new way to work with Spring called Spring Boot. You’ll see how Spring Boot can take away much of the boilerplate configuration required in a Spring application, enabling you to focus on the business functionality. Code conventions and downloads There are many code examples throughout this book. These examples will always appear in a fixed-width code font like this. 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/SpringinActionFourthEdition. Author Online Purchase of Spring in Action, Fourth Edition includes free access to a private web forum run by Manning Publications where you can make comments about the book, ask technical questions, and receive help from the author and from other users. To ABOUT THIS BOOKxxiv access the forum and subscribe to it, point your web browser to www.manning.com/ SpringinActionFourthEdition. 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 author Craig Walls is a senior engineer with Pivotal as the project lead for Spring Social and Spring Sync, and is the author of Manning’s Spring in Action books, now updated in this Fourth Edition. He’s a zealous promoter of the Spring Framework, speaking fre- quently at local user groups and conferences and writing about Spring. When he’s not slinging code, Craig spends as much time as he can with his wife, two daughters, two birds, and two dogs. About the cover illustration The figure on the cover of Spring in Action, Fourth Edition, is “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 tourist 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 dis- tinctiveness and individuality of the world’s towns and provinces just two hundred 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 inhabitants 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 Spring does a lot of things. But underneath all of the fantastic functionality it adds to enterprise development, its primary features are dependency injection (DI) and aspect-oriented programming (AOP). Starting in chapter 1, “Springing into action,” I’ll give you a quick overview of the Spring Framework, including a quick overview of DI and AOP in Spring and show how they help with decoupling application components. In chapter 2, “Wiring beans,” we’ll dive deeper into how to piece together the components of an application. We’ll look at automatic configuration, Java- based configuration, and XML configuration options offered by Spring. Chapter 3, “Advanced wiring,” goes beyond the basics and shows you a few tricks and techniques that will help you get the most power out of Spring, includ- ing conditional configuration, dealing with ambiguity when autowiring, scoping, and the Spring Expression Language. Chapter 4, “Aspect-oriented Spring,” explores how to use Spring’s AOP fea- tures to decouple system-wide services (such as security and auditing) from the objects they service. This chapter sets the stage for later chapters such as chap- ters 9, 13, and 14 where you’ll see how to leverage Spring AOP for declarative security and caching. 3 Springing into action It’s a good time to be a Java developer. In its almost 20 year history, Java has seen some good times and some bad times. Despite a handful of rough spots, such as applets, Enterprise JavaBeans (EJB), Java Data Objects (JDO), and countless logging frameworks, Java has enjoyed a rich and diverse history as the platform on which much enterprise software has been built. And Spring has been a big part of that story. In its early days, Spring was created as an alternative to heavier enterprise Java technologies, especially EJB. Spring offered a lighter and leaner programming model as compared to EJB. It empowered plain old Java objects (POJOs) with pow- ers previously only available using EJB and other enterprise Java specifications. Over time, EJB and the Java 2 Enterprise Edition (J2EE) evolved. EJB started offering a simple POJO-oriented programming model of its own. Now EJB employs ideas such as dependency injection (DI) and aspect-oriented programming (AOP), arguably inspired by the success of Spring. This chapter covers Spring’s bean container Exploring Spring’s core modules The greater Spring ecosystem What’s new in Spring 4 CHAPTER 1 Springing into action Although J2EE (now known as JEE) was able to catch up with Spring, Spring never stopped moving forward. Spring has continued to progress in areas where, even now, JEE is just starting to explore or isn’t innovating at all. Mobile development, social API integration, NoSQL databases, cloud computing, and big data are just a few areas where Spring has been and is innovating. And the future continues to look bright for Spring. As I said, it’s a good time to be a Java developer. This book is an exploration of Spring. In this chapter, we’ll examine Spring at a high level, providing you with a taste of what Spring is about. This chapter will give you a good idea of the types of problems Spring solves, and it will set the stage for the rest of the book. 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 (Wrox, 2002, http:// amzn.com/0764543857). 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 EJB. But Spring’s usefulness isn’t limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling. A bean by any other name… Although Spring uses the words bean and JavaBean lib- erally when referring to application components, this doesn’t mean a Spring compo- nent must follow the JavaBeans specification to the letter. A Spring component can be any type of POJO. In this book, I assume a loose definition of JavaBean, which is synon- ymous 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 fundamental 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 POJOs Loose coupling through DI and interface orientation Declarative programming through aspects and common conventions Eliminating boilerplate code with 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. 5Simplifying Java 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 easy-target example of such an inva- sive programming model was EJB 2-era stateless session beans. But even though early EJBs were such an easy target, invasive programming could easily be found in earlier versions of Struts, WebWork, Tapestry, and countless other Java specifications and frameworks. 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 it’s otherwise a POJO. To illustrate, consider the HelloWorldBean class shown in the following listing. package com.habuma.spring; public class HelloWorldBean { public String sayHello() { return "Hello World"; } } As you can see, this is a simple, garden-variety Java class—a POJO. Nothing special about it indicates that it’s a Spring component. Spring’s non-invasive programming model means this class could function equally well in a Spring application as it could in a non-Spring application. Despite their simple form, POJOs can be powerful. One of the ways Spring empow- ers POJOs is by assembling them using DI. Let’s see how DI 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 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. HOW DI WORKS 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 per- form 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. Listing 1.1 Spring doesn’t make any unreasonable demands on HelloWorldBean. This is all you need. 6 CHAPTER 1 Springing into action package com.springinaction.knights; public class DamselRescuingKnight implements Knight { private RescueDamselQuest quest; public DamselRescuingKnight() { this.quest = new RescueDamselQuest(); } public void embarkOnQuest() { quest.embark(); } } As you can see, DamselRescuingKnight creates its own quest, a RescueDamselQuest, in the constructor. This makes a DamselRescuingKnight tightly coupled to a Rescue- DamselQuest 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() method is called. But there’s no clear way to accomplish that here. Unfortunately, DamselRescuingKnight will remain untested. Coupling is a two-headed beast. On the one hand, tightly coupled code is difficult to test, difficult to reuse, and difficult to understand, and it 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 some- how. Coupling is necessary but should be carefully managed. With DI, 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. As illustrated in figure 1.1, dependencies are injected into the objects that need them. To illustrate this point, let’s look at BraveKnight in the next listing: a knight who’s not only brave, but also capable of embarking on any kind of quest that comes along. Listing 1.2 A DamselRescuingKnight can only embark on RescueDamselQuests. Tightly coupled to RescueDamselQuest Foo Bar Baz Injected into Injected into Figure 1.1 Dependency injection involves giving an object its dependencies as opposed to an object having to acquire those dependencies on its own. 7Simplifying Java development package com.springinaction.knights; public class BraveKnight implements Knight { private Quest quest; public BraveKnight(Quest quest) { this.quest = quest; } public void embarkOnQuest() { quest.embark(); } } As you can see, BraveKnight, unlike DamselRescuingKnight, doesn’t create his own quest. Instead, he’s given a quest at construction time as a constructor argument. This is a type of DI known as constructor injection. What’s more, the quest he’s given is typed as Quest, an interface that all quests imple- ment. So BraveKnight could embark on a RescueDamselQuest, a SlayDragonQuest, a MakeRoundTableRounderQuest, or any other Quest implementation he’s given. The point 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 on, as 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 implementa- tion or how they’re instantiated), then the dependency can be swapped out with a dif- ferent implementation without the depending object knowing the difference. One of the most common ways a dependency is swapped out is with a mock imple- mentation during testing. You were unable to adequately test DamselRescuingKnight due to tight coupling, but you can easily test BraveKnight by giving it a mock imple- mentation 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() { Quest mockQuest = mock(Quest.class); BraveKnight knight = new BraveKnight(mockQuest); knight.embarkOnQuest(); verify(mockQuest, times(1)).embark(); } } Listing 1.3 A BraveKnight is flexible enough to take on any Quest he’s given. Listing 1.4 To test BraveKnight, inject it with a mock Quest. Quest is injected Create mock Quest Inject mock Quest 8 CHAPTER 1 Springing into action Here you use a mock object framework known as Mockito to create a mock implemen- tation 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 verify that the mock Quest’s embark() method was called exactly once. INJECTING A QUEST INTO A KNIGHT Now that the BraveKnight class is written in such a way that you can give a knight any quest you want, how can you specify which Quest to give him? Suppose, for instance, that you’d like for the BraveKnight to embark on a quest to slay a dragon. Perhaps SlayDragonQuest, shown in the following listing, would be appropriate. package com.springinaction.knights; import java.io.PrintStream; public class SlayDragonQuest implements Quest { private PrintStream stream; public SlayDragonQuest(PrintStream stream) { this.stream = stream; } public void embark() { stream.println("Embarking on quest to slay the dragon!"); } } As you can see, SlayDragonQuest implements the Quest interface, making it a good fit for BraveKnight. You may also notice that rather than lean on System.out .println() like many small getting-started Java samples, SlayDragonQuest more generically asks for a PrintStream through its constructor. The big question here is, how can you give SlayDragonQuest to BraveKnight? And how can you give a Print- Stream to SlayDragonQuest? The act of creating associations between application components is commonly referred to as wiring. In Spring, there are many ways to wire components together, but a common approach has always been via XML. The next listing shows a simple Spring configuration file, knights.xml, that wires a BraveKnight, a SlayDragonQuest, and a PrintStream together. Here, BraveKnight and SlayDragonQuest are declared as beans in Spring. In the case of the BraveKnight bean, it’s constructed, passing a reference to the SlayDragon- Quest bean as a constructor argument. Meanwhile, the SlayDragonQuest bean decla- ration uses the Spring Expression Language to pass System.out (which is a PrintStream) to SlayDragonQuest’s constructor. If XML configuration doesn’t suit your tastes, you might like to know that Spring also allows you to express configuration using Java. For example, here you see a Java- based equivalent to listing 1.6. package com.springinaction.knights.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import com.springinaction.knights.BraveKnight; import com.springinaction.knights.Knight; import com.springinaction.knights.Quest; import com.springinaction.knights.SlayDragonQuest; @Configuration public class KnightConfig { @Bean public Knight knight() { return new BraveKnight(quest()); } @Bean public Quest quest() { return new SlayDragonQuest(System.out); } } Whether you use XML-based or Java-based configuration, the benefits of DI are the same. Although BraveKnight depends on a Quest, it doesn’t know what type of Quest it will be given or where that Quest will come from. Likewise, SlayDragonQuest Listing 1.7 Spring offers Java-based configuration as an alternative to XML. Inject quest bean Create SlayDragonQuest 10 CHAPTER 1 Springing into action depends on a PrintStream, but it isn’t coded with knowledge of how that Print- Stream comes to be. Only Spring, through its configuration, knows how all the pieces come together. This makes it possible to change those dependencies with no changes to the depending classes. This example has shown a simple approach to wiring beans in Spring. Don’t con- cern yourself too much with the details right now. We’ll dig more into Spring configu- ration when we get to chapter 2. We’ll also look at other ways that beans can be wired in Spring, including a way to let Spring automatically discover beans and create the relationships between them. Now that you’ve declared the relationship between BraveKnight and a Quest, you need to load 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 it loads its configuration. When the beans in knights.xml are declared in an XML file, an appropriate choice for application context might be ClassPathXmlApplicationContext.1 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 Class- PathXmlApplicationContext to load knights.xml and to get a reference to the Knight object. package com.springinaction.knights; import org.springframework.context.support. ClassPathXmlApplicationContext; public class KnightMain { public static void main(String[] args) throws Exception { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext( "META-INF/spring/knight.xml"); Knight knight = context.getBean(Knight.class); knight.embarkOnQuest(); context.close(); } } 1 For Java-based configurations, Spring offers AnnotationConfigApplicationContext. Listing 1.8 KnightMain.java loads the Spring context containing a Knight. Load Spring context Get knight bean Use knight 11Simplifying Java development 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 he was given. Note that this class knows nothing about which type of Quest your 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 DI, I encourage you to look at Dhanji R. Prasanna’s Dependency Injection (Manning, 2009, www.manning.com/ prasanna/), which covers DI in fine detail. Now let’s look at another of Spring’s Java-simplifying strategies: declarative pro- gramming through aspects. 1.1.3 Applying aspects Although DI makes it possible to tie software components together loosely, aspect- oriented programming (AOP) enables you to capture functionality that’s used throughout your application in reusable components. AOP is often defined as a technique that promotes separation of concerns in a soft- ware system. Systems are composed of several components, each responsible for a spe- cific piece of functionality. But often these components also carry additional respon- sibilities beyond their core functionality. System services such as logging, transaction management, and security often find their way into components whose core responsi- bilities is something else. These system services are commonly referred to as cross-cut- ting 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 system-wide 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 that adds 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 on the right. Not only does each object know that it’s being logged, secured, and involved in a transactional context, but each object also is responsible for performing those services for itself. 12 CHAPTER 1 Springing into action AOP makes it possible to modularize these services and then apply them declaratively to the components they should affect. This results in components that are more cohe- sive and that focus on their own specific concerns, completely ignorant of any system 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 exist. This is a powerful concept, because it keeps the security, transaction, and log- ging concerns 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. Figure 1.2 Calls to system-wide concerns such as logging and security are often scattered about in modules where those tasks are not their primary concern. Student service Billing service Course service Instructor service Content service Logging module Security module Transaction manager Figure 1.3 Using AOP, system-wide concerns blanket the components they impact. This leaves the application components to focus on their specific business functionality. Secur ity modul e Logging m odule Transaction manager Student service Instructor service Course service Billing service Content service 13Simplifying Java development 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 BraveK- night using the services of a minstrel. The following listing shows the Minstrel class you might use. package com.springinaction.knights; import java.io.PrintStream; public class Minstrel { private PrintStream stream; public Minstrel(PrintStream stream) { this.stream = stream; } public void singBeforeQuest() { stream.println("Fa la la, the knight is so brave!"); } public void singAfterQuest() { stream.println("Tee hee hee, 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. In both cases, the Minstrel sings of the knight’s deeds via a PrintStream injected through its constructor. It should be simple to work this into your code—you can just inject it into Brave- Knight, right? Let’s make the appropriate tweaks to BraveKnight to use Minstrel. The next listing shows a first attempt at bringing BraveKnight and Minstrel together. package com.springinaction.knights; public class BraveKnight implements Knight { private Quest quest; private Minstrel minstrel; public BraveKnight(Quest quest, Minstrel minstrel) { Listing 1.9 A Minstrel is a musically inclined logging system from medieval times. Listing 1.10 A BraveKnight that must call Minstrel methods Called before quest Called after quest 14 CHAPTER 1 Springing into action this.quest = quest; this.minstrel = minstrel; } public void embarkOnQuest() throws QuestException { minstrel.singBeforeQuest(); quest.embark(); minstrel.singAfterQuest(); } } That should do the trick. Now all you need to do is go back to your Spring configura- tion to declare a Minstrel bean and inject it into the BraveKnight bean’s constructor. But hold on… Something doesn’t seem right. Is it really within the knight’s range of concern to manage his minstrel? It seems to me that minstrels should just do their job without having to be asked to do so. After all, that’s a minstrel’s job—to sing about the knight’s endeavors. Why should the knight have to keep reminding the minstrel? Furthermore, because the knight needs to know about the minstrel, you’re forced to inject Minstrel into BraveKnight. This not only complicates the BraveKnight code but also makes me wonder if you’d ever want a knight who didn’t have a minstrel. What if Minstrel is null? Should you 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. > Listing 1.11 Declaring the Minstrel as an aspect Should a knight manage his own minstrel? 15Simplifying Java development Here you’re using Spring’s aop configuration namespace to declare that the Minstrel bean is an aspect. First you declare Minstrel as a bean. Then you refer to that bean in the element. Defining the aspect further, you declare (using ) that before the embarkOnQuest() method is executed, the Minstrel’s singBefore- Quest() should be called. This is called before advice. And you (using ) declare that the singAfterQuest() method should be called after embarkOnQuest() has executed. This is known as after advice. In both cases, the pointcut-ref attribute refers to a pointcut named embark. This pointcut is defined in the preceding element with an expression attri- bute set to select where the advice should be applied. The expression syntax is AspectJ’s pointcut expression language. Don’t worry if you don’t know AspectJ or the details of how AspectJ pointcut expressions are written. We’ll talk more about Spring AOP later, in chapter 4. For now it’s enough to know that you’ve asked Spring to call Minstrel’s singBeforeQuest() and singAfterQuest() methods before and after BraveKnight embarks on a quest. That’s all there is to it! With a tiny bit of XML, you’ve turned Minstrel into a Spring aspect. Don’t worry if this doesn’t make complete sense yet—you’ll see plenty more examples of Spring AOP in chapter 4 that should help clear this up. For now, there are two important points to take away from this example. First, Minstrel is still a POJO—nothing about it indicates that it’s to be used as an aspect. Instead, Minstrel became an aspect when you declared it as such in the Spring context. Second, and most important, Minstrel can be applied to BraveKnight without BraveKnight needing to explicitly call on it. In fact, BraveKnight remains completely unaware of Minstrel’s existence. I should also point out that although you used some Spring magic to turn Minstrel into an aspect, it was declared as a Spring first. The point is that you Declare Minstrel bean Define pointcut Declare before advice Declare after advice 16 CHAPTER 1 Springing into action can do anything with Spring aspects that you can do with other Spring beans, such as inject them with dependencies. Using aspects to sing about knights can be fun. But Spring’s AOP can be used for even more practical things. As you’ll see later, Spring AOP can be employed to pro- vide services such as declarative transactions and security (chapters 9 and 14). But for now, let’s look at one more way that Spring simplifies Java development. 1.1.4 Eliminating boilerplate code with templates Have you ever written some code and then felt like you’d already written the same code before? That’s not déjà vu, my friend. That’s boilerplate code—the code that you often have to write over and over again to accomplish common and otherwise simple tasks. Unfortunately, there are a lot of places where Java APIs involve a bunch of boiler- plate code. A common example of boilerplate code can be seen when working with JDBC to query data from a database. If you’ve ever worked with JDBC, you’ve probably written something similar to the following. public Employee getEmployeeById(long id) { Connection conn = null; PreparedStatement stmt = null; ResultSet rs = null; try { conn = dataSource.getConnection(); stmt = conn.prepareStatement( "select id, firstname, lastname, salary from " + "employee where id=?"); stmt.setLong(1, id); rs = stmt.executeQuery(); Employee employee = null; if (rs.next()) { employee = new Employee(); employee.setId(rs.getLong("id")); employee.setFirstName(rs.getString("firstname")); employee.setLastName(rs.getString("lastname")); employee.setSalary(rs.getBigDecimal("salary")); } return employee; } catch (SQLException e) { } finally { if(rs != null) { try { rs.close(); } catch(SQLException e) {} } if(stmt != null) { try { stmt.close(); } catch(SQLException e) {} } Listing 1.12 Many Java APIs, such as JDBC, involve writing boilerplate code. Select employee Create object from data What should be done here? Clean up mess 17Simplifying Java development if(conn != null) { try { conn.close(); } catch(SQLException e) {} } } return null; } As you can see, this JDBC code queries the database for an employee’s name and sal- ary. But I’ll bet you had to look hard to see that. That’s because the small bit of code that’s specific to querying for an employee is buried in a heap of JDBC ceremony. You first have to create a connection, then create a statement, and finally query for the results. And, to appease JDBC’s anger, you must catch SQLException, a checked excep- tion, even though there’s not a lot you can do if it’s thrown. Finally, after all is said and done, you have to clean up the mess, closing down the connection, statement, and result set. This could also stir JDBC’s anger, so you must catch SQLException here as well. What’s most notable about listing 1.12 is that much of it is the exact same code you’d write for pretty much any JDBC operation. Little of it has anything to do with querying for an employee, and much of it is JDBC boilerplate. JDBC is not alone in the boilerplate code business. Many activities require similar boilerplate code. JMS, JNDI, and the consumption of REST services often involve a lot of commonly repeated code. Spring seeks to eliminate boilerplate code by encapsulating it in templates. Spring’s JdbcTemplate makes it possible to perform database operations without all the ceremony required by traditional JDBC. For example, using Spring’s SimpleJdbcTemplate (a specialization of Jdbc- Template that takes advantage of Java 5 features), the getEmployeeById() method can be rewritten so that its focus is on the task of retrieving employee data and not catering to the demands of the JDBC API. The following shows what such an updated getEmployeeById() method might look like. public Employee getEmployeeById(long id) { return jdbcTemplate.queryForObject( "select id, firstname, lastname, salary " + "from employee where id=?", new RowMapper() { public Employee mapRow(ResultSet rs, int rowNum) throws SQLException { Employee employee = new Employee(); employee.setId(rs.getLong("id")); employee.setFirstName(rs.getString("firstname")); employee.setLastName(rs.getString("lastname")); employee.setSalary(rs.getBigDecimal("salary")); return employee; Listing 1.13 Templates let your code focus on the task at hand. SQL query Map results to object 18 CHAPTER 1 Springing into action } }, id); } As you can see, this new version of getEmployeeById() is much simpler and acutely focused on selecting an employee from the database. The template’s queryFor- Object() method is given the SQL query, a RowMapper (for mapping result set data to a domain object), and zero or more query parameters. What you don’t see in get- EmployeeById() is any of the JDBC boilerplate from before. Everything is handled inside the template. I’ve shown you how Spring attacks complexity in Java development using POJO- oriented development, DI, aspects, and templates. Along the way, I showed you how to configure beans and aspects in XML-based configuration files. But how do those files get loaded? And what are they loaded into? Let’s look at the Spring container, the place where your application’s beans reside. 1.2 Containing your beans In a Spring-based application, your appli- cation objects live in the Spring container. As illustrated in figure 1.4, the container creates the objects, wires them together, configures them, and manages their com- plete lifecycle from cradle to grave (or new to finalize(), as the case may be). In the next chapter, you’ll see how to configure Spring so it knows what objects it should create, configure, and wire together. First, though, it’s important to get to know the container where your objects will be hanging out. Understand- ing the container will help you grasp how your objects will be managed. The container is at the core of the Spring Framework. Spring’s container uses DI to manage the components that make up an application. This includes creating associa- tions between collaborating components. As such, these objects are cleaner and easier to understand, they support reuse, and they’re easy to unit test. There’s no single Spring container. Spring comes with several container imple- mentations that can be categorized into two distinct types. Bean factories (defined by the org.springframework.beans.factory.BeanFactory interface) are the simplest of containers, providing basic support for DI. Application contexts (defined by the org.springframework.context.ApplicationContext interface) build on the notion of a bean factory by providing application-framework services, such as the ability to Specify query parameter Spring container Figure 1.4 In a Spring application, objects are created, are wired together, and live in the Spring container. 19Containing your beans resolve textual messages from a properties file and the ability to publish application events to interested event listeners. Although it’s possible to work with Spring using either bean factories or applica- tion contexts, bean factories are often too low-level for most applications. Therefore, application contexts are preferred over bean factories. We’ll focus on working with application contexts and not spend any more time talking about bean factories. 1.2.1 Working with an application context Spring comes with several flavors of application context. Here are a few that you’ll most likely encounter: AnnotationConfigApplicationContext—Loads a Spring application context from one or more Java-based configuration classes AnnotationConfigWebApplicationContext—Loads a Spring web application context from one or more Java-based configuration classes ClassPathXmlApplicationContext—Loads a context definition from one or more XML files located in the classpath, treating context-definition files as class- path resources FileSystemXmlApplicationContext—Loads a context definition from one or more XML files in the filesystem XmlWebApplicationContext—Loads context definitions from one or more XML files contained in a web application We’ll talk more about AnnotationConfigWebApplicationContext and XmlWeb- ApplicationContext in chapter 8 when we discuss web-based Spring applications. For now, let’s load the application context from the filesystem using FileSystemXml- ApplicationContext or from the classpath using ClassPathXmlApplicationContext. Loading an application context from the filesystem or from the classpath is similar to how you load beans into a bean factory. For example, here’s how you’d load a File- SystemXmlApplicationContext: ApplicationContext context = new FileSystemXmlApplicationContext("c:/knight.xml"); Similarly, you can load an application context from the application’s classpath using ClassPathXmlApplicationContext: ApplicationContext context = new ClassPathXmlApplicationContext("knight.xml"); The difference between using FileSystemXmlApplicationContext and ClassPathXml- ApplicationContext is that FileSystemXmlApplicationContext looks for knight.xml in a specific location within the filesystem, whereas ClassPathXmlApplicationContext looks for knight.xml anywhere in the classpath (including JAR files). 20 CHAPTER 1 Springing into action Alternatively, if you’d rather load your application context from a Java configura- tion, you can use AnnotationConfigApplicationContext: ApplicationContext context = new AnnotationConfigApplicationContext( com.springinaction.knights.config.KnightConfig.class); Instead of specifying an XML file from which to load the Spring application context, AnnotationConfigApplicationContext has been given a configuration class from which to load beans. With an application context in hand, you can retrieve beans from the Spring con- tainer by calling the context’s getBean() method. Now that you know the basics of how to create a Spring container, let’s take a closer look at the lifecycle of a bean in the bean container. 1.2.2 A bean’s life In a traditional Java application, the lifecycle of a bean is simple. Java’s new keyword is used to instantiate the bean, and it’s ready to use. Once the bean is no longer in use, it’s eligible for garbage collection and eventually goes to the big bit bucket in the sky. In contrast, the lifecycle of a bean in a Spring container is more elaborate. It’s important to understand the lifecycle of a Spring bean, because you may want to take advantage of some of the opportunities that Spring offers to customize how a bean is created. Figure 1.5 shows the startup lifecycle of a typical bean as it’s loaded into a Spring application context. Instantiate Bean is ready to use Populate properties BeanNameAware’s setBeanName() BeanFactoryAware’s setBeanFactory() Pre-initialization BeanPostProcessors Post-initialization BeanPostProcessors InitializingBean ’s afterPropertiesSet() Call custom init-method Container is shutdown DisposableBean’s destroy() Call custom destroy-method ApplicationContextAware’s setApplicationContext() Figure 1.5 A bean goes through several steps between creation and destruction in the Spring container. Each step is an opportunity to customize how the bean is managed in Spring. 21Surveying the Spring landscape As you can see, a bean factory performs several setup steps before a bean is ready to use. Let’s break down figure 1.5 in more detail: 1 Spring instantiates the bean. 2 Spring injects values and bean references into the bean’s properties. 3 If the bean implements BeanNameAware, Spring passes the bean’s ID to the set- BeanName() method. 4 If the bean implements BeanFactoryAware, Spring calls the setBeanFactory() method, passing in the bean factory itself. 5 If the bean implements ApplicationContextAware, Spring calls the set- ApplicationContext() method, passing in a reference to the enclosing appli- cation context. 6 If the bean implements the BeanPostProcessor interface, Spring calls its post- ProcessBeforeInitialization() method. 7 If the bean implements the InitializingBean interface, Spring calls its after- PropertiesSet() method. Similarly, if the bean was declared with an init- method, then the specified initialization method is called. 8 If the bean implements BeanPostProcessor, Spring calls its postProcess- AfterInitialization() method. 9 At this point, the bean is ready to be used by the application and remains in the application context until the application context is destroyed. 10 If the bean implements the DisposableBean interface, Spring calls its destroy() method. Likewise, if the bean was declared with a destroy-method, the specified method is called. Now you know how to create and load a Spring container. But an empty container isn’t much good by itself; it doesn’t contain anything unless you put something in it. To achieve the benefits of Spring DI, you must wire your application objects into the Spring container. We’ll go into bean wiring in more detail in chapter 2. First, let’s survey the modern Spring landscape to see what the Spring Framework is made up of and what the latest versions of Spring have to offer. 1.3 Surveying the Spring landscape As you’ve seen, the Spring Framework is focused on simplifying enterprise Java devel- opment through DI, AOP, and boilerplate reduction. Even if that were all Spring did, it’d be worth using. But there’s more to Spring than meets the eye. Within the Spring Framework proper, you’ll find several ways that Spring can ease Java development. But beyond the Spring Framework is a greater ecosystem of proj- ects that build on the core framework, extending Spring into areas such as web ser- vices, REST, mobile, and NoSQL. Let’s first break down the core Spring Framework to see what it brings to the table. Then we’ll expand our sights to review the other members of the greater Spring portfolio. 22 CHAPTER 1 Springing into action 1.3.1 Spring modules When you download the Spring distribu- tion and dig into its libs folder, you’ll find several JAR files. As of Spring 4.0, there are 20 distinct modules in the Spring Framework distribution, with three JAR files for each module (the binary class library, the source JAR file, and a JavaDoc JAR file). The complete list of library JAR files is shown in figure 1.6. These modules can be arranged into six categories of functionality, as illus- trated in figure 1.7. Taken as a whole, these modules give you everything you need to develop enterprise-ready applications. But you don’t have to base your application fully on the Spring Framework. You’re free to choose the modules that suit your appli- cation and look to other options when Data access & integration JDBC OXM Transaction ORM JMS Web and remoting Web Web servlet Web portlet WebSocket Aspect-oriented programming AOP Aspects Instrumentation Instrument TomcatInstrument Core Spring container Beans Core Context Expression Context support Testing Test Messaging Figure 1.7 The Spring Framework is made up of six well-defined module categories. Figure 1.6 Spring 4.0 is made up of 20 distinct modules. 23Surveying the Spring landscape Spring doesn’t fit the bill. Spring even offers integration points with several other frameworks and libraries so that you don’t have to write them yourself. Let’s look at each of Spring’s modules, one at a time, to see how each fits in the overall Spring picture. CORE SPRING CONTAINER The centerpiece of the Spring Framework is a container that manages how the beans in a Spring-enabled application are created, configured, and managed. In this mod- ule is the Spring bean factory, which is the portion of Spring that provides DI. Build- ing on the bean factory, you’ll find several implementations of Spring’s application context, each of which provides a different way to configure Spring. In addition to the bean factory and application context, this module also supplies many enterprise services such as email, JNDI access, EJB integration, and scheduling. All of Spring’s modules are built on top of the core container. You’ll implicitly use these classes when you configure your application. We’ll discuss the core module throughout this book, starting in chapter 2 where we’ll dig deep into Spring DI. SPRING’S AOP MODULE Spring provides rich support for aspect-oriented programming in its AOP module. This module serves as the basis for developing your own aspects for your Spring- enabled application. Like DI, AOP supports loose coupling of application objects. But with AOP, application-wide concerns (such as transactions and security) are decoupled from the objects to which they’re applied. We’ll dig into Spring’s AOP support in chapter 4. DATA ACCESS AND INTEGRATION Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. Spring’s JDBC and data-access objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaning- ful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL error messages! For those who prefer using an object-relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module. Spring’s ORM support builds on the DAO sup- port, providing a convenient way to build DAOs for several ORM solutions. Spring doesn’t attempt to implement its own ORM solution but does provide hooks into sev- eral popular ORM frameworks, including Hibernate, Java Persistence API, Java Data Objects, and iBATIS SQL Maps. Spring’s transaction management supports each of these ORM frameworks as well as JDBC. You’ll see how Spring’s template-based JDBC abstraction can greatly simplify JDBC code when we look at Spring data access in chapter 10. This module also includes a Spring abstraction over the Java Message Service (JMS) for asynchronous integration with other applications through messaging. And, as of 24 CHAPTER 1 Springing into action Spring 3.0, this module includes the object-to-XML mapping features that were origi- nally part of the Spring Web Services project. In addition, this module uses Spring’s AOP module to provide transaction- management services for objects in a Spring application. WEB AND REMOTING The Model-View-Controller (MVC) paradigm is a commonly accepted approach to build- ing web applications such that the user interface is separate from the application logic. Java has no shortage of MVC frameworks, with Apache Struts, JSF, WebWork, and Tapestry being among the most popular MVC choices. Even though Spring integrates with several popular MVC frameworks, its web and remoting module comes with a capable MVC framework that promotes Spring’s loosely coupled techniques in the web layer of an application. We’ll look at Spring’s MVC framework in chapters 5–7. In addition to user-facing web applications, this module also provides several remoting options for building applications that interact with other applications. Spring’s remoting capabilities include Remote Method Invocation (RMI), Hessian, Bur- lap, JAX-WS, and Spring’s own HTTP invoker. Spring also offers first-class support for exposing and consuming REST APIs. In chapter 15, we’ll check out Spring remoting. And you’ll learn how to create and consume REST APIs in chapter 16. INSTRUMENTATION Spring’s instrumentation module includes support for adding agents to the JVM. Spe- cifically, it provides a weaving agent for Tomcat that transforms class files as they’re loaded by the classloader. If that sounds like a lot to understand, don’t worry too much about it. The instru- mentation provided by this module has a narrow set of use cases and we won’t be deal- ing with this module at all in this book. TESTING Recognizing the importance of developer-written tests, Spring provides a module ded- icated to testing Spring applications. In this module you’ll find a collection of mock object implementations for writing unit tests against code that works with JNDI, servlets, and portlets. For integration-level testing, this module provides support for loading a collection of beans in a Spring application context and working with the beans in that context. Throughout this book, many of the examples will be driven by tests, utilizing the testing facilities offered by Spring. 1.3.2 The Spring portfolio When it comes to Spring, there’s more than meets the eye. In fact, there’s more than what comes in the Spring Framework download. If you stop at just the core Spring Framework, you’ll miss out on a wealth of potential afforded by the larger Spring 25Surveying the Spring landscape portfolio. The whole Spring portfolio includes several frameworks and libraries that build on the core Spring Framework and on each other. All together, the entire Spring portfolio brings the Spring programming model to almost every facet of Java development. It would take several volumes to cover everything the Spring portfolio has to offer, and much of it is outside the scope of this book. But we’ll look at some of the elements of the Spring portfolio; here’s a taste of what lies beyond the core Spring Framework. SPRING WEB FLOW Spring Web Flow builds on Spring’s core MVC framework to provide support for build- ing conversational, flow-based web applications that guide users toward a goal (think wizards or shopping carts). We’ll talk more about Spring Web Flow in chapter 8, and you can learn more about it at http://projects.spring.io/spring-webflow/. SPRING WEB SERVICES Although the core Spring Framework provides for declaratively publishing Spring beans as web services, those services are based on an arguably architecturally inferior contract-last model. The contract for the service is determined from the bean’s inter- face. Spring Web Services offers a contract-first web services model where service implementations are written to satisfy the service contract. I won’t be talking about Spring-WS in this book, but you can read more about it at http://docs.spring.io/spring-ws/site/. SPRING SECURITY Security is a critical aspect of many applications. Implemented using Spring AOP, Spring Security offers a declarative security mechanism for Spring-based applications. You’ll see how to add Spring Security to an application’s web layer in chapter 9. We’ll return to Spring Security again in chapter 14 to examine how to secure method invocations. For further exploration, Spring Security’s home page is at http:// projects.spring.io/spring-security/. SPRING INTEGRATION Many enterprise applications must interact with other enterprise applications. Spring Integration offers implementations of several common integration patterns in Spring’s declarative style. We won’t cover Spring Integration in this book, but if you want more information, look at Spring Integration in Action by Mark Fisher, Jonas Partner, Marius Bogoevici, and Iwein Fuld (Manning, 2012, www.manning.com/fisher/). Or you can visit the Spring Integration home page at http://projects.spring.io/spring-integration/. SPRING BATCH When it’s necessary to perform bulk operations on data, nothing beats batch process- ing. If you’re going to be developing a batch application, you can use Spring’s robust, POJO-oriented development model to do it using Spring Batch. 26 CHAPTER 1 Springing into action Spring Batch is beyond the scope of this book, but Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, and Olivier Bazoud will enlighten you in their book, Spring Batch in Action (Manning, 2011, www.manning.com/templier/). You can also learn about Spring Batch from its home page at http://projects.spring.io/spring-batch/. SPRING DATA Spring Data makes it easy to work with all kinds of databases in Spring. Although the relational database has been ubiquitous in enterprise applications for many years, mod- ern applications are recognizing that not all data is best served by columns and rows in a table. A new breed of databases, commonly referred to as NoSQL databases,2 offer new ways of working with data that are more fitting than the traditional relational database. Whether you’re using a document database like MongoDB, a graph database such as Neo4j, or even a traditional relational database, Spring Data offers a simplified pro- gramming model for persistence. This includes, for many database types, an auto- matic repository mechanism that creates repository implementations for you. We’ll look at using Spring Data to simplify Java Persistence API (JPA) development in chapter 11 and then expand the discussion to include a few NoSQL databases in chapter 12. SPRING SOCIAL Social networking is a rising trend on the internet, and more and more applications are being outfitted with integration into social networking sites such as Facebook and Twitter. If this is the kind of thing that interests you, you’ll want to look at Spring Social, a social networking extension to Spring. But Spring Social is about more than just tweets and friends. Despite its name, Spring Social is less about the word social and more about the word connect. It helps you connect your Spring application with REST APIs, including many that may not have any social purpose to them. Due to space constraints, we won’t cover Spring Social in this book. But if you’re interested in how Spring can help you connect with Facebook or Twitter, have a look at the Getting Started guides at https://spring.io/guides/gs/accessing-facebook/ and https://spring.io/guides/gs/accessing-twitter/. SPRING MOBILE Mobile applications are another significant area of software development. Smart- phones and tablet devices are taking over as the preferred client for many users. Spring Mobile is a new extension to Spring MVC to support development of mobile web applications. SPRING FOR ANDROID Related to Spring Mobile is the Spring Android project. This project aims to bring some of the simplicity afforded by the Spring Framework to development of native 2 I prefer the term non-relational or schema-less over NoSQL. Calling these databases NoSQL places the blame on the query language and not the database model. 27What’s new in Spring applications for Android-based devices. Initially, this project is offering a version of Spring’s RestTemplate that can be used in an Android application. It also works with Spring Social to enable native Android apps to connect with REST APIs. I won’t discuss Spring for Android in this book, but you can learn more about it at http://projects.spring.io/spring-android/. SPRING BOOT Spring greatly simplifies many programming tasks, reducing or even eliminating much of the boilerplate code you might normally be required to write without it. Spring Boot is an exciting new project that takes an opinionated view of developing with Spring to simplify Spring itself. Spring Boot heavily employs automatic configuration techniques that can elimi- nate most (and in many cases, all) Spring configuration. It also provides several starter projects to help reduce the size of your Spring project build files, whether you’re using Maven or Gradle. We’ll look at Spring Boot near the end of the book in chapter 21. 1.4 What’s new in Spring When the third edition of this book went to press, the latest version of Spring was ver- sion 3.0.5. That was around three years ago, and a lot has changed since then. The Spring Framework has seen three significant releases—3.1, 3.2, and now 4.0—each bringing new features and improvements to ease application development. And sev- eral of the other members of the Spring portfolio have undergone major changes. This edition of Spring in Action has been updated to cover many of the most excit- ing and useful features in these releases. But for now, let’s briefly size up what’s new in Spring. 1.4.1 What was new in Spring 3.1? Spring 3.1 had several useful new features and improvements, many of which were focused on simplifying and improving configuration. In addition, Spring 3.1 provided declarative caching support as well as many improvements to Spring MVC. Here’s a brief list of some of the highlights of Spring 3.1: To address the common issue of selecting distinct configurations for various environments (such as development, test, and production), Spring 3.1 intro- duced environment profiles. Profiles make it possible, for instance, to select a different data source bean depending on which environment the application is deployed in. Building on Spring 3.0’s Java-based configuration, Spring 3.1 added several enable annotations to switch on certain features of Spring with a single annotation. Declarative caching support made its way into Spring, making it possible to declare caching boundaries and rules with simple annotations, similar to how you could already declare transaction boundaries. 28 CHAPTER 1 Springing into action A new c namespace brought constructor injection the same succinct attribute- oriented style as Spring 2.0’s p namespace brought to property injection. Spring began to support Servlet 3.0, including the ability to declare servlets and filters in Java-based configuration instead of web.xml. Improvements to Spring’s JPA support made it possible to completely configure JPA in Spring without needing a persistence.xml file. Spring 3.1 also included several enhancements to Spring MVC: Automatic binding of path variables to model attributes @RequestMappingproduces and consumes attributes, for matching against a request’s Accept and Content-Type headers A @RequestPart annotation that enables binding parts of a multipart request to handler method parameters Support for flash attributes (attributes that survive a redirect) and a Redirect- Attributes type to carry the flash attributes between requests Just as important as what was new in Spring 3.1 is what was no longer available in Spring as of Spring 3.1. Specifically, Spring’s JpaTemplate and JpaDaoSupport classes were deprecated in favor of native EntityManager usage. Even though they were dep- recated, they were still around in Spring 3.2. But you shouldn’t use them, because they weren’t upgraded to support JPA 2.0 and have been removed in Spring 4. Now let’s look at what was new in Spring 3.2. 1.4.2 What was new in Spring 3.2? Whereas Spring 3.1 was largely focused on configuration improvements with a small set of other enhancements, including Spring MVC enhancements, Spring 3.2 was primarily a Spring MVC-focused release. Spring MVC 3.2 boasted the following improvements: Spring 3.2 controllers can take advantage of Servlet 3’s asynchronous requests to spin off request processing in separate threads, freeing up the servlet thread to process more requests. Although Spring MVC controllers have been easily testable as POJOs since Spring 2.5, Spring 3.2 included a Spring MVC test framework for writing richer tests against controllers, asserting their behavior as controllers, but without a servlet container. In addition to improved controller testing, Spring 3.2 included support for testing RestTemplate-based clients without sending requests to the real REST endpoint. An @ControllerAdvice annotation enables common @ExceptionHandler, @InitBinder, and @ModelAttributes methods to be collected in a single class and applied to all controllers. Prior to Spring 3.2, full content negotiation support was only available via ContentNegotiatingViewResolver. But in Spring 3.2, full content negotiation 29What’s new in Spring became available throughout Spring MVC, even on controller methods relying on message converters for content consumption and production. Spring MVC 3.2 included a new @MatrixVariable annotation for binding a request’s matrix variables to handler method parameters. The abstract base class AbstractDispatcherServletInitializer can be used for conveniently configuring DispatcherServlet without web.xml. Likewise, a subclass named AbstractAnnotationConfigDispatcherServletInitializer can be used when you wish to configure Spring with Java-based configuration. The ResponseEntityExceptionHandler class was added to be used as an alter- native to DefaultHandlerExceptionResolver. ResponseEntityException- Handler methods return ResponseEntity