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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.