Preface
In 2004, Erik Hatcher traveled from a very wet Virginia to a usually dry Austin and got lucky. Barton Creek was up. Together, we braved the cold and windy conditions, and had one of the best kayaking days of our lives. In 2000, three friends and I drove east in March to run the Little River through the Great Smokey Mountains. As we put in, two inches of snow frosted the landscape, and flakes lightly dusted our boats on another memorable, incredible day, ripping through rapids like the Sinks (I walked around it) and the Elbow (I ran it, and didn’t sleep for a week afterwards). The cold weather that starts a new paddling season adds an indescribable kind of energy to a run. There’s just something magical about the thaw—the springtime.
In the Java community, we’re encountering a Spring of a different kind. This one follows the great freeze of Enterprise JavaBeans 2.x (EJB). Tens of thousands of applications lay in frigid, near-death conditions in this well-intentioned, massive block of ice. EJB can suck the life right out of a developer if you’re not careful, and sometimes, even if you are:
Though developers use automated testing as a cornerstone practice, you can’t test EJB applications well at all. The container is too big to start in a test case, and objects can’t live outside of the container.
EJB is incredibly intrusive. True, it’s designed to shield your business objects from the details of transactions, persistence, security, remoting and messaging. It just does a terrible job. Your application becomes a slave to the EJB way.
EJB forces unnatural design decisions. EJB applications must use dumbed-down value objects instead of rich domain objects. Like the Pied Piper, EJB capabilities like remoting entice developers to distribute applications in unsound ways. Limitations of EJB persistence force suboptimal designs, because they don’t support critical concepts like inheritance.
And so, after years of plodding through monolithic EJB architectures and design patterns that are nothing more than workarounds for obvious problems, the whole enterprise Java community is ready for the Spring thaw. Rather than the large dominant vendors, a new breed of lightweight development processes and open source frameworks is supplying the heat.
Still, many developers resist change. To them, EJB is worth the pain, because of the value of declarative services like transactions and remoting. Breaking these ideas out of mainline business logic makes applications simpler, cleaner, and easier to maintain. But if declarative services are so important, why stop with just the declarative services provided by the container? Why not make a general model that makes it easy to attach services to any POJO?
In the end, I don’t kayak and code for the same reasons. I kayak to have fun. I code to make money, and to get stuff done. If there’s a good way to provide persistence (such as Hibernate or JDO) or transactions (such as JTA or JDBC), I should be able to tell the computer to make some thing transactional, or persistent, or remote, or secure.
In Spring, you can make an object secure, remote, or transactional with a couple of lines of XML. The resulting application is simple and clean. In Spring, you can work less and go home, because you can strip away a whole lot of the redundant code that you tend to see in most J2EE applications. You won’t be nearly as burdened with meaningless detail. In Spring, you can often change your mind without the consequences bleeding through your entire application. You’ll adapt much more quickly than you ever could before.
That’s why I’m ready for the thaw.
How to Use This Book
As with all books in the Developer’s Notebook series, we’re not going to pretend to give you a definitive reference. Instead, we hope to get you going quickly. You’ll do so by getting your hands dirty. You’ll work through one example after another. In the end, we hope you’ll find the energy and promise of the Spring framework. Before you go too far, let me point you to the chapters that might be most interesting to you.
You can get the examples for this book, both in completed form and for each chapter and lab individually. Since Spring’s such a wide-ranging project, you may want to skip a chapter here or there. I’m not going to restate the table of contents. In fact, most developer notebook readers probably skip the preface until the third or fourth reading anyway. Still, I should give you a couple of pointers that could save you some time.
If you’re interested in the basics of dependency injection, you’ll want to pay close attention to Chapter 1.
If you like to build user interfaces, you’ll like Chapters Chapter 2, Chapter 3, and Chapter 9. If you’re interested in Spring’s proprietary way of doing things, check out Chapters Chapter 2 (WebMVC) and Chapter 9 (the Spring Rich sandbox project). Chapter 3 is dedicated to JSF and Struts.
If you’re into persistence, you’ll like Chapter 4 and Chapter 5. Chapter 4 deals with JDBC, and Chapter 5 dives into true ORM solutions. Many people adopt Spring because it makes persistence so much easier.
If you’re hazy on AOP and how Spring’s version works, you’ll like Chapter 6, but if you don’t plan to build your own services, you could easily skip it.
In short, look to this book for examples. Unlike examples in pure code form, these will talk to you. As I’ve read through examples, I’ve often wondered why some decisions were made. With this developer notebook, you’ll have a running commentary. We hope you enjoy it.
Conventions Used in This Book
The following typographical conventions are used in this book:
- Plain text
Indicates menu titles, menu options, menu buttons, and keyboard accelerators (such as Alt and Ctrl).
- Italic
Indicates new terms, URLs, email addresses, filenames, and file extensions.
-
Constant width Indicates extensions, pathnames, Unix utilities, commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, or the output from commands.
-
Constant width bold Shows commands or other text that should be typed literally by the user.
-
Constant width italic Shows text that should be replaced with user-supplied values.
Using Code Examples
This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Spring: A Developer’s Notebook, by Bruce A. Tate and Justin Gehtland. Copyright 2005 O’Reilly Media, Inc., 0-596-00910-0.”
Comments and Questions
Please address comments and questions concerning this book to the publisher:
| O’Reilly Media, Inc. |
| 1005 Gravenstein Highway North |
| Sebastopol, CA 95472 |
| (800) 998-9938 (in the United States or Canada) |
| (707) 829-0515 (international or local) |
| (707) 829-0104 (fax) |
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:
| http://www.oreilly.com/catalog/springadn |
To comment or ask technical questions about this book, send email to:
| [email protected] |
For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at:
| http://www.oreilly.com |
Safari Enabled
When you see a Safari® Enabled icon on the cover of your favorite technology book, it means the book is available online through the O’Reilly Network Safari Bookshelf.
Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top technology books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it free at http://safari.oreilly.com.
Collective Acknowledgments
There’s more than a good author behind a good book, and this one is no exception. To be interesting, a Developer’s Notebook needs a compelling technology, and Spring certainly fits that bill. Thanks to Rod Johnson and Juergen Hoeller, for meticulously breathing life into these ideas. We’re in awe of what you’ve accomplished. Many of you probably bought the book because of another name on the cover, O’Reilly. That’s no accident. Thanks to all of the supporting people who make it so. You’ll find many of them in the back of this book, but we want to call a little more attention to a few of them.
Thanks to Kyle Hart, for your tireless promotion of this book, and of Better, Faster, Lighter Java. Thanks to Mike Loukides, both for your friendship, and for your guiding touch. You’ve got the sixth sense that all great editors have, and we genuinely appreciate the little time that we’ve spent together.
Good books also need good reviewers. Thanks to Mike’s mystery reviewer, who provided the harsh, critical commentary that often wakes an author team up, and alerts them to danger. Thanks especially to David Rupp. We added you as an afterthought, and you turned out to be the best reviewer of the bunch. Even so, some mistakes could have escaped their tireless eyes. Those mistakes are ours, and not the reviewers.
We also would like to thank the gracious folks at JetBrains for a great IDE. It helped us write this book much more quickly than we otherwise would have. As always, we thank those Java users groups and events like JavaGruppen in Denmark, for giving us the opportunity to hone this message.
Acknowledgments from Bruce
I’d like to thank Rod Johnson for friendship and opportunities. I wish you the best of luck with Interface 21. I thank Jay Zimmerman, for all you’ve done to help promote me and my books. I love your win-win style of business, even when I’m taking a three-stop flight to save you eight bucks. You’ve built a marvelous thing, and I’m glad that people are starting to recognize that. I’d also like to thank the many customers who treated me so well on the road, and looked over this book as it was under development—especially Trek and ProClarity. I hope you’re able to put it into practice, and that it helps you do some great things.
Most authors wind up thanking their families, and there’s a good reason for that. Family stirs the passion that it takes to write a good book. Family bears the brunt of the frustration and after-hours work that books always generate. I dare you to try to stay frustrated in the midst of little girl giggles. Thanks to Kayla and Julia for your laughter and smiles. Families encourage the best in us. Thanks to Maggie, my inspiration, for staying beside me and believing in me when others didn’t, and for being there—even when I’m not. I love you more than you’ll ever know.
Acknowledgments from Justin
No technical work like this one exists in a vacuum; the decision to write a book is based on the imperative pressed on you by great new technologies that need to be talked about. As such, without Rod Johnson and Juergen Hoeller, I’d never have had the opportunity to write this book in the first place. Secondly, the book itself is shaped by the people you hang out with while writing it, so thanks to all the folks on the No Fluff tour, who make up 98% of my social life: Ted Neward, Dave Thomas, David Geary, Erik Hatcher, Dion Almaer, Jason Hunter, Nick Liesecki, Mike Clark, and of course, Jay Zimmerman. Each of you is an inspiration.
Thanks (again) to Stuart Halloway, a great business partner and even better influence. Your tireless dedication to learning new things, even if you forget them minutes later, is a compelling beacon.
Finally, I too have to thank my family. My daughter, Zoe, who is now learning to say all kinds of wonderful things like “car” and “house” and “protein” and “Cthulhu,” proves to me every day that life is beautiful. And my wife, Lisa, who, through whatever twists and turns I throw at her, manages to say “That sounds like a great idea.” Your tireless support and unconditional love keep me going.