This change upgrades the spring-framework build to AspectJ 1.7.1 to
ensure compatibility. We remain backward-compatible to at least AJ
1.6.12 (the previous version), and likely back to 1.6.7.
AJ 1.7 allows for weaving Java 7 bytecode, particularly with regard
to invokedynamic instructions, and furthermore makes improvements to
the aspectj language itself to allow users to take advantage of Java 7-
style language features within aspects. See [1] for details.
[1]: http://eclipse.org/aspectj/doc/released/README-170.html
Issue: SPR-10079
- Support external Javadoc links using Gradle's javadoc.options.links
- Fix all other Javadoc warnings, such as typos, references to
non-existent (or no longer existent) types and members, etc,
including changes related to the Quartz 2.0 upgrade (SPR-8275) and
adding the HTTP PATCH method (SPR-7985).
- Suppress all output for project-level `javadoc` tasks in order to
hide false-negative warnings about cross-module @see and @link
references (e.g. spring-core having a @see reference to spring-web).
Use the `--info` (-i) flag to gradle at any time to see project-level
javadoc warnings without running the entire `api` task. e.g.
`gradle :spring-core:javadoc -i`
- Favor root project level `api` task for detection of legitimate
Javadoc warnings. There are now zero Javadoc warnings across the
entirety of spring-framework. Goal: keep it that way.
- Remove all @link and @see references to types and members that exist
only in Servlet <= 2.5 and Hibernate <= 4.0, favoring 3.0+ and 4.0+
respectively. This is necessary because only one version of each of
these dependencies can be present on the global `api` javadoc task's
classpath. To that end, the `api` task classpath has now been
customized to ensure that the Servlet 3 API and Hibernate Core 4 jars
have precedence.
- SPR-8896 replaced our dependency on aspectjrt with a dependency on
aspectjweaver, which is fine from a POM point of view, but causes
a spurious warning to be emitted from the ant iajc task that it
"cannot find aspectjrt on the classpath" - even though aspectjweaver
is perfectly sufficient. In the name of keeping the console quiet, a
new `rt` configuration has been added, and aspectjrt added as a
dependency to it. In turn, configurations.rt.asPath is appended to
the iajc classpath during both compileJava and compileTestJava for
spring-aspects.
Issue: SPR-10078, SPR-8275, SPR-7985, SPR-8896
Prior to this change, aggregated javadoc has been written to an 'api'
dir and reference docs into a 'reference' dir. This shorter naming is
desirable, but is not compatible with historical naming under 3.1.x as
defined by the Ant+Ivy Spring Build.
For example, URLs are currently as follows:
http://static.springsource.org/spring-framework/docs/3.1.3.RELEASE/javadoc-apihttp://static.springsource.org/spring-framework/docs/3.1.x/javadoc-apihttp://static.springsource.org/spring-framework/docs/current/javadoc-api
Particularly with regard to the 'current' link, we do not want to
break this url scheme with the shortened 'api' directory naming. Of
course this compatibility can be preserved with symlinks, but this makes
the release process that much more complicated and fragile.
This commit ensures that the naming is 'javadoc-api' and
'spring-framework-reference', consistent with historical convention.
We can always add a symlinking scheme to add the shorter 'api' and
'reference' options after the fact if desired.
Added "clearCache()" method to CachingMetadataReaderFactory, for clearing the metadata cache once not needed anymore - in particular when the MetadataReaderFactory instance is long-lived. Also added "setMetadataReaderFactory" method to ClassPathScanningCandidateComponentProvider, analogous to ConfigurationClassPostProcessor.
This commit adds documentation to the "New Features and Enhancements in
Spring 3.2" section of the reference manual regarding new testing
features.
Issue: SPR-9941
This commit adds documentation for the following new features in the
Spring TestContext Framework within the Testing chapter of the reference
manual.
- @WebAppConfiguration and context caching
- WebDelegatingSmartContextLoader
- AnnotationConfigWebContextLoader
- GenericXmlWebContextLoader
- Loading a WebApplicationContext in integration tests
- ServletTestExecutionListener
- Testing request and session scoped beans
Issue: SPR-9864
This commit adds Javadoc documentation for the WebApplicationContext
testing support that was recently introduced in the Spring TestContext
Framework.
Issue: SPR-9864
Update tiles.xml files used with tests to reference tiles-config_3_0
instead of tiles-config_2_1 DTD.
Prior to this commit tiles based tests would fail when building
offline or behind a proxy server.
Previously it was cumbersome to associate data or behavior to a
DeferredResult because it was marked as final and had no extension
points.
Now DeferredResult is non-final which allows subclasses to associate
additional data and behavior to it.
Issue: SPR-10059
Previously the 'merge from' project's configurations exclude rules were
not used in the dynamically created 'merge into' project configurations.
This meant that the pom generation for 'merge into' project did not
exclude the dependencies from the 'merge from' project's configuration
excludes.
Now the exclude rules are copied into the dynamically created
'merge into' project's configurations.
Refactor the existing merge-artifacts script to a full Gradle plugin.
The new plugin uses a 'merge' extension in favor of Gradle 'ext'
configuration and can be applied to all projects in a multi-module
build.
Any project that defines a 'merge.into' project will now implicitly
receive a dependency to that project. Furthermore other projects
with a dependency on 'merge.into' will receive a direct project
link within the IDE. For example: 'spring-webmvc-tiles3'
is merged into 'spring-webmvc' and 'spring-test-mvc' depends
on 'spring-webmvc'. Within the IDE 'spring-test-mvc' will show
dependencies to both 'spring-webmvc' and 'spring-webmvc-tiles'.
Issue: SPR-10042
Replace existing 'optional' and 'provided' Spring specific build
extensions with a new Gradle propdeps-plugin. Optional and Provided
dependencies are now defined use dependency configurations.
The new plugin does not currently support the notion of optional
runtime dependencies. All optional dependencies are implicitly
part of the 'compile' scope. This is an intentional design decision
that aims to keep both the plugin and the build simple. Since optional
dependencies are non-transitive this restriction should not cause
any real problems for existing users. The only existing dependency
affected is 'commons-io' in the 'spring-beans' project, however, this
was an optional compile scope dependency in the previous Spring 3.1
release.
Both provided and optional dependencies are no longer exported from
generated eclipse .classpath files. This fixes several tests that
would previously fail when running within eclipse. The servlet-api
specific elements of ide.gradle are also no longer required.
Issue: SPR-9656, SPR-10070
Upgrade to the latest stable release of log4j. The previous 'jms'
and 'jmx' exclusions are not longer required since these have now
been marked as optional dependencies in the upstream POM.
Update all Gradle files to use a consistent style when specifying
dependencies. All dependencies are now specified using parentheses,
for example:
scope("group:artifat:version")
or scope(project(":projectname"))
When Spr9799XmlConfigTests and Spr9799AnnotationConfigTests were
created, there were issues with the classpath related to slf4j
dependencies that made it impossible for these classes to reside in the
spring-test module. Consequently, these tests were added to the
spring-test-mvc module. However, the issues with slf4j have since been
resolved in the Gradle build, and this commit therefore moves these test
classes to the spring-test module where they belong.
Issue: SPR-9799
This change introduces a new AllEncompassingFormHttpMessageConverter
class that adds JSON and XML converters for individual mime parts of
a multi-part request. The new converter is used in place of the
previously used XmlAwareFormHttpMessageConverter.
Issue: SPR-10055
The servlet spec treats any jar in WEB-INF/lib as a web fragment:
"A plain old jar file in the WEB-INF/lib directory with no web-
fragment.xml is also considered a fragment" (section 8.2.1)
This change adds a web-fragment.xml giving the web fragment an
explicit name, "spring_web", and indicating there is no need
to scan for Servlet annotations in the spring-web.jar itself
through metadata-complete=true.
This allows applications that choose to include only specific
web fragments, through the <absolute-ordering> element in web.xml
to also include the "spring_web" fragment, in order to enable scanning
for WebApplicationInitializer types.
tiles-core-3 brings in a dependency on jcl-overl-slf4 which causes
an slf4j delegation loop as explained at [1] when tests run inside
Eclipse. Other modules that depend on tiles-core like
(tiles-servlet, tiles-jsp) have also had the exclusion added since
they seem to bring it in as well.
[1] http://www.slf4j.org/codes.html#jclDelegationLoop
Prevously the FrameworkServlet created a new ServletRequestAttributes
instance for every request, unless the RequestContextHolder already
contained an instance whose type is not ServletRequestAttributes.
The main intent was that if RequestContextHolder contains a
PortletRequestAttributes, it should be left in place.
This change does an "instanceof" check against the request in
RequestContextHolder instead of an "equals" check on the type.
It still leaves PortletRequestAttributes in place but also allows
the previous request to be any sub-class of ServletRequestAttributes.
Issue: SPR-10025
- Deleted unused imports.
- Switched from junit.framework.Assert to org.junit.Assert, since the
former is deprecated as of JUnit 4.11.
- Suppressed warnings for continued deprecated usage of
junit.framework.Assert.
Spring Framework 3.2 M2 added the ability to map requests using only
file extensions registered through the configured through a
ContentNeotiationManager, as opposed to allowing any file extension
(i.e. ".*"). The MVC namespace the MVC Java config automatically
register extensions such as ".json" and ".xml" depending on libraries
found on the classpath. That in turn causes issues in cases where
additional extensions are in use but not registered (e.g. ".html").
This change ensures that matching with registered file extensions only
works only if explicitly enabled through a property on
RequestMappingHandlerMapping.
Issue: SPR-10061, SPR-8474
Rossen Stoyanchev
Chris Beams
Phillip Webb
Juergen Hoeller
Sam Brannen
Rob Winch