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 seeChapter 4, New Features and Enhancements in Spring Framework 3.2
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. 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
@WebAppConfiguration
support of spring-test
for loading Spring configuration, then
inject a WebApplicationContext
into the test and use it to create a MockMvc
. See
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. Hamcrest Core is now a required transitive dependency of junit
, and users
may therefore need to remove any exclusions on hamcrest-core
that they had previously
configured for their build.
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.
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.
simpleJdbcTemplate
instance variable has been deprecated in favor of the
new jdbcTemplate
instance variable.
simpleJdbcTemplate
instance variable has been deprecated in favor of the
new jdbcTemplate
instance variable.
JdbcTestUtils
which now contains all of the
functionality previously available in SimpleJdbcTestUtils
.