If you have been using the Spring Framework for some time, you will be aware that Spring has just undergone a major revision.
This revision includes a host of new features, and a lot of the existing functionality has been reviewed and improved. In fact, so much of Spring is shiny and improved that the Spring development team decided that the next release of Spring merited an increment of the version number; and so Spring 2.0 was announced in December 2005 at the Spring Experience conference in Florida.
This chapter is a guide to the new and improved features of Spring 2.0. It is intended to provide a high-level summary so that seasoned Spring architects and developers can become immediately familiar with the new Spring 2.0 functionality. For more in-depth information on the features, please refer to the corresponding sections hyperlinked from within this chapter.
Some of the new and improved functionality described below has been (or will be) backported into the Spring 1.2.x release line. Please do consult the changelogs for the 1.2.x releases to see if a feature has been backported.
One of the areas that contains a considerable number of 2.0 improvements is Spring's IoC container.
Spring XML configuration is now even easier, thanks to the advent of the new XML configuration syntax based on XML Schema. If you want to take advantage of the new tags that Spring provides (and the Spring team certainly suggest that you do because they make configuration less verbose and easier to read), then do read the section entitled Appendix A, XML Schema-based configuration.
On a related note, there is a new, updated DTD for Spring 2.0 that you may wish to reference if you cannot take advantage of the XML Schema-based configuration. The DOCTYPE declaration is included below for your convenience, but the interested reader should definitely read the 'spring-beans-2.0.dtd' DTD included in the 'dist/resources' directory of the Spring 2.0 distribution.
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "http://www.springframework.org/dtd/spring-beans-2.0.dtd">
Previous versions of Spring had IoC container level support for exactly two distinct bean scopes (singleton and prototype). Spring 2.0 improves on this by not only providing a number of additional scopes depending on the environment in which Spring is being deployed (for example, request and session scoped beans in a web environment), but also by providing 'hooks' (for want of a better word) so that Spring users can create their own scopes.
It should be noted that although the underlying (and internal) implementation for singleton- and prototype-scoped beans has been changed, said change is totally transparent to the end user... no existing configuration needs to change, and no existing configuration will break.
Both the new and the original scopes are detailed in the section entitled Section 3.4, “Bean scopes”.
Not only is XML configuration easier to write, it is now also extensible.
What 'extensible' means in this context is that you, as an application developer, or (more likely) as a third party framework or product vendor, can write custom tags that other developers can then plug into their own Spring configuration files. This allows you to have your own domain specific language (the term is used loosely here) of sorts be reflected in the specific configuration of your own components.
Implementing custom Spring tags may not be of interest to every single application developer or enterprise architect using Spring in their own projects. We expect third-party vendors to be highly interested in developing custom configuration tags for use in Spring configuration files.
The extensible configuration mechanism is documented in Appendix B, Extensible XML authoring.
Spring 2.0 has a much improved AOP offering. The Spring AOP framework itself is markedly easier to configure in XML, and significantly less verbose as a result; and Spring 2.0 integrates with the AspectJ pointcut language and @AspectJ aspect declaration style. The chapter entitled Chapter 6, Aspect Oriented Programming with Spring is dedicated to describing this new support.
Spring 2.0 introduces new schema support for defining aspects backed by regular Java objects. This support takes advantage of the AspectJ pointcut language and offers fully typed advice (i.e. no more casting and Object[] argument manipulation). Details of this support can be found in the section entitled Section 6.3, “Schema-based AOP support”.
Spring 2.0 also supports aspects defined using the @AspectJ annotations. These aspects can be shared between AspectJ and Spring AOP, and require (honestly!) only some simple configuration. Said support for @AspectJ aspects is discussed in Section 6.2, “@AspectJ support”.
The way that transactions are configured in Spring 2.0 has been changed significantly. The previous 1.2.x style of configuration continues to be valid (and supported), but the new style is markedly less verbose and is the recommended style. Spring 2.0 also ships with an AspectJ aspects library that you can use to make pretty much any object transactional - even objects not created by the Spring IoC container.
The chapter entitled Chapter 9, Transaction management contains all of the details.
Spring 2.0 ships with a JPA abstraction layer that is similar in intent to Spring's JDBC abstraction layer in terms of scope and general usage patterns.
If you are interested in using a JPA-implementation as the backbone of your persistence layer, the section entitled Section 12.6, “JPA” is dedicated to detailing Spring's support and value-add in this area.
Prior to Spring 2.0, Spring's JMS offering was limited to sending messages and the synchronous receiving of messages. This functionality (encapsulated in the JmsTemplate class) is great, but it doesn't address the requirement for the asynchronous receiving of messages.
Spring 2.0 now ships with full support for the reception of messages in an asynchronous fashion, as detailed in the section entitled Section 19.4.2, “Asynchronous Reception - Message-Driven POJOs”.
There are some small (but nevertheless notable) new classes in the Spring Framework's JDBC support library. The first, NamedParameterJdbcTemplate, provides support for programming JDBC statements using named parameters (as opposed to programming JDBC statements using only classic placeholder ('?') arguments.
Another of the new classes, the SimpleJdbcTemplate, is aimed at making using the JdbcTemplate even easier to use when you are developing against Java 5+ (Tiger).
The web tier support has been substantially improved and expanded in Spring 2.0.
A rich JSP tag library for Spring MVC was the JIRA issue that garnered the most votes from Spring users (by a wide margin).
Spring 2.0 ships with a full featured JSP tag library that makes the job of authoring JSP pages much easier when using Spring MVC; the Spring team is confident it will satisfy all of those developers who voted for the issue on JIRA. The new tag library is itself covered in the section entitled Section 13.9, “Using Spring's form tag library”, and a quick reference to all of the new tags can be found in the appendix entitled Appendix E, spring-form.tld.
For a lot of projects, sticking to established conventions and having reasonable defaults is just what the projects need... this theme of convention-over-configuration now has explicit support in Spring MVC. What this means is that if you establish a set of naming conventions for your Controllers and views, you can substantially cut down on the amount of XML configuration that is required to setup handler mappings, view resolvers, ModelAndView instances, etc. This is a great boon with regards to rapid prototyping, and can also lend a degree of (always good-to-have) consistency across a codebase.
Spring MVC's convention-over-configuration support is detailed in the section entitled Section 13.11, “Convention over configuration”
Spring 2.0 ships with a Portlet framework that is conceptually similar to the Spring MVC framework. Detailed coverage of the Spring Portlet framework can be found in the section entitled Chapter 16, Portlet MVC Framework.
This final section outlines all of the other new and improved Spring 2.0 features and functionality.
Spring 2.0 now has support for beans written in languages other than Java, with the currently supported dynamic languages being JRuby, Groovy and BeanShell. This dynamic language support is comprehensively detailed in the section entitled Chapter 24, Dynamic language support.
The Spring Framework now has support for Notifications; it is also possible to exercise declarative control over the registration behavior of MBeans with an MBeanServer.
Spring 2.0 offers an abstraction around the scheduling of tasks. For the interested developer, the section entitled Section 23.4, “The Spring TaskExecutor abstraction” contains all of the details.
If you are one of the lucky few to be developing projects using Java 5 (Tiger), you will be pleased to know that Spring 2.0 now has some compelling support for Tiger. Below is a set of pointers to Spring Java 5-only features.
This final section details issues that may arise during any migration from Spring 1.2.x to Spring 2.0.
Feel free to take this next statement with a pinch of salt, but upgrading to Spring 2.0 from a Spring 1.2 application should simply be a matter of dropping the Spring 2.0 jar into the appropriate location in your application's directory structure.
The keyword from the last sentence was of course the “should”. Whether the upgrade is seamless or not depends on how much of the Spring APIs you are using in your code. Spring 2.0 removed pretty much all of the classes and methods previously marked as deprecated in the Spring 1.2.x codebase, so if you have been using such classes and methods, you will of course have to use alternative classes and methods (some of which are summarised below).
With regards to configuration, Spring 1.2.x style XML configuration is 100%, satisfaction-guaranteed compatible with the Spring 2.0 library. Of course if you are still using the Spring 1.2.x DTD, then you won't be able to take advantage of some of the new Spring 2.0 functionality (such as scopes and easier AOP and transaction configuration), but nothing will blow up.
The suggested migration strategy is to drop in the Spring 2.0 jar(s) to benefit from the improved code present in the release (bug fixes, optimisations, etc.). You can then, on an incremental basis, choose to start using the new Spring 2.0 features and configuration. For example, you could choose to start configuring just your aspects in the new Spring 2.0 style; it is perfectly valid to have 90% of your configuration using the old-school Spring 1.2.x configuration (which references the 1.2.x DTD), and have the other 10% using the new Spring 2.0 configuration (which references the 2.0 DTD or XSD). Bear in mind that you are not forced to upgrade your XML configuration should you choose to drop in the Spring 2.0 libraries.
For a comprehensive list of changes, consult the 'changelog.txt' file that is located in the top level directory of the Spring Framework 2.0 distribution.
The packaging of the Spring Framework jars has changed quite substantially between the 1.2.x and 2.0 releases. In particular, there are now dedicated jars for the JDO, Hibernate 2/3, TopLink ORM integration classes: they are no longer bundled in the core 'spring.jar' file anymore.
Spring 2.0 ships with XSDs that describe Spring's XML metadata format in a much richer fashion than the DTD that shiiped with previous versions. The old DTD is still fully supported, but if possible you are encouraged to reference the XSD files at the top of your bean definition files.
One thing that has changed in a (somewhat) breaking fashion is the way that bean scopes are defined. If you are using the Spring 1.2 DTD you can continue to use the 'singleton' attribute. You can however choose to reference the new Spring 2.0 DTD which does not permit the use of the 'singleton' attribute, but rather uses the 'scope' attribute to define the bean lifecycle scope.
A number of classes and methods that previously were marked as @deprecated have been totally removed from the Spring 2.0 codebase. The Spring team decided that the 2.0 release marked a fresh start of sorts, and that any deprecated 'cruft' was better excised now instead of continuing to haunt the codebase for the forseeable future.
As mentioned previously, for a comprehensive list of changes, consult the 'changelog.txt' file that is located in the top level directory of the Spring Framework 2.0 distribution.
The following classes/interfaces have all been removed from the Spring 2.0 codebase.
ResultReader : use the RowMapper interface instead.
BeanReferenceFactoryBean : use the available alias mechanisms instead
BeanDefinitionRegistryBuilder : use the convenience methods on the BeanDefinitionReaderUtils class instead
BeanFactoryBootstrap : consider using a BeanFactoryLocator or a custom bootstrap class instead
RequestUtils : use ServletRequestUtils instead
Please note that support for Apache OJB was totally removed from the main Spring source tree; the Apache OJB integration library is still available, but can be found in it's new home in the Spring Modules project.
A number of the sample applications have also been updated to showcase the new and improved features of Spring 2.0, so do take the time to investigate them. The aforementioned sample applications can be found in the 'samples' directory of the full Spring distribution ('spring-with-dependecies.[zip|tar.gz]').
Said distribution also ships with a number of so-called showcase applications. Each showcase application provides fully working examples, focussed on demonstrating exactly one new Spring 2.0 feature at a time. The idea is that you can take the code in these showcases and experiment with it, as opposed to having to create your own small project to test out each new Spring 2.0 feature. Please be advised that the scope of these showcase applications is deliberately limited; the domain model (if there even is one) consists of maybe one or two classes, and typical enterprise concerns such as security and transactional integrity are deliberately omitted.
The Spring reference documentation has also substantially been updated to reflect all of the above features new in Spring 2.0.
While every effort has been made to ensure that there are no errors in this documentation, some errors may nevertheless have crept in. If you do spot any typos or even more serious errors, and you can spare a few cycles during lunch, please do bring the error to the attention of the Spring team by raising an issue.
Special thanks to Arthur Loder for his tireless proofreading of the Spring Framework reference documentation and Javadocs.