Appendix C. Migrating to Spring Framework 3.2

In this appendix we discuss what users will want to know when upgrading to Spring Framework 3.2. For a general overview of features, please see Chapter 4, New Features and Enhancements in Spring Framework 3.2

C.1 Newly optional dependencies

Certain inter-module dependencies are now optional at the Maven POM level where they were once required. For example, spring-tx and its dependence on spring-context. This may result in ClassNotFoundErrors or other similar problems for users that have been relying on transitive dependency management to pull in affected downstream spring-* . To resolve this problem, simply add the appropriate missing jars to your build configuration.

C.2 EHCache support moved to spring-context-support

Along with Spring's new JCache support, the EHCache support classes in the org.springframework.cache.ehcache package moved from the spring-context module to spring-context-support.

C.3 Inlining of spring-asm jar

In versions 3.0 and 3.1, we published a discrete spring-asm containing repackaged org.objectweb.asm 3.x sources. As of Spring Framework 3.2, we have upgraded to org.objectweb.asm 4.0 and done away with the separate module jar, favoring inlining these classes directly within spring-core. This should cause no migration issue for most users; but on the off chance that you have spring-asm declared directly within your project's build script, you'll want to remove it when upgrading to Spring Framework 3.2.

C.4 Explicit CGLIB dependency no longer required

In prior versions, users of Spring's subclass-based AOP proxies (e.g. via proxy-target-class="true") and @Configuration class support were required to declare an explicit dependency on CGLIB 2.2. As of Spring Framework 3.2, we now repackage and inline the newly-released CGLIB 3.0.

This means greater convenience for users, as well as correct functionality for Java 7 users who are creating subclass proxies of types that contain invokedynamic bytecode instructions. Repackaging CGLIB internally ensures no classpath conflicts with other third party frameworks that may depend on other versions of CGLIB.

C.5 For OSGi users

OSGi metadata is no longer published within individual Spring Framework jar MANIFEST.MF files. Please see this announcement for more information about how users can get OSGi-ready versions of Spring Framework 3.2 jars.

C.6 MVC Java Config and MVC Namespace

As explained in Section 17.15.4, “Configuring Content Negotiation”, both the MVC Java config and the MVC namespace register extensions such as .json and .xml if the corresponding classpath dependencies are present. That means controller methods may now return JSON or XML formatted content if those extensions are present in the request URI, even if the 'Accept' header doesn't request those media types.

The newly added support for matrix variables is explained in the section called “Matrix Variables”. To preserve backward compatibility, by default, semicolon content is removed from incoming request URIs and therefore @MatrixVariable cannot be used without additional configuration. However, when using the MVC Java config and the MVC namespace, semicolon content is left in the URI so that matrix variables are automatically supported. The removal of semicolon content is controlled through the UrlPathHelper property of RequestMappingHandlerMapping.

C.7 Decoding of URI Variable Values

URI variable values now get decoded when UrlPathHelper.setUrlDecode is set to false. See SPR-9098.

C.8 HTTP PATCH method

The DispatcherServlet now allows the HTTP PATCH method where previously it didn't.

C.9 Tiles 3

Besides the version number change, the set of Tiles dependencies has also changed. You will need to have a subset or all of tiles-request-api, tiles-api, tiles-core, tiles-servlet, tiles-jsp, tiles-el.

C.10 Spring MVC Test standalone project

If migrating from the spring-test-mvc standalone project to the spring-test module in Spring Framework 3.2, you will need to adjust the root package to be org.springframework.test.web.servlet.

You will no longer be able to use the MockMvcBuilders annotationConfigSetup and xmlConfigSetup options. Instead you'll need to switch to using the @WebApplicationContext support of spring-test for loading Spring configuration, then inject a WebApplicationContext into the test and use it to create a MockMvc. Section 11.3.6, “Spring MVC Test Framework” for details.

C.11 Spring Test Dependencies

The spring-test module has been upgraded to depend on JUnit 4.11 (junit:junit), TestNG 6.5.2 (org.testng:testng), and Hamcrest Core 1.3 (org.hamcrest:hamcrest-core). Each of these dependencies is declared as an optional dependency in the Maven POM. Furthermore, it is important to note that the JUnit team has stopped inlining Hamcrest Core within the junit:junit Maven artifact as of JUnit 4.11. Thus, if your existing JUnit-based tests make use of Hamcrest matchers that were previously available directly within the junit:junit JAR, you will now need to explicitly declare a dependency on org.hamcrest:hamcrest-core, org.hamcrest:hamcrest-library, or org.hamcrest:hamcrest-all.

C.12 Public API changes

C.12.1 JDiff reports

Select JDiff reports are now being published to provide users with a convenient means of understanding what's changed between versions. Going forward these will be published between each minor version, e.g. from 3.1.3.RELEASE to 3.1.4.RELEASE; from the latest maintenance version to the latest GA release, e.g. 3.1.3.RELEASE to 3.2.0.RELEASE; and in between each milestone and/or RC for users who are tracking next-generation development, e.g. 3.2.0.RC2 to 3.2.0.RELEASE.

C.12.2 Deprecations

The following packages and types have been wholly or partially deprecated in Spring Framework 3.2 and may be removed in a future version. Click through to the linked Javadoc for each item for exact details. See also the complete list of deprecations in the framework.