From a programming model perspective, @RequestMapping methods now
support two new return value types:
* java.util.concurrent.Callable - used by Spring MVC to obtain the
return value asynchronously in a separate thread managed transparently
by Spring MVC on behalf of the application.
* org.springframework.web.context.request.async.DeferredResult - used
by the application to produce the return value asynchronously in a
separate thread of its own choosing.
The high-level idea is that whatever value a controller normally
returns, it can now provide it asynchronously, through a Callable or
through a DeferredResult, with all remaining processing --
@ResponseBody, view resolution, etc, working just the same but
completed outside the main request thread.
From an SPI perspective, there are several new types:
* AsyncExecutionChain - the central class for managing async request
processing through a sequence of Callable instances each representing
work required to complete request processing asynchronously.
* AsyncWebRequest - provides methods for starting, completing, and
configuring async request processing.
* StandardServletAsyncWebRequest - Servlet 3 based implementation.
* AsyncExecutionChainRunnable - the Runnable used for async request
execution.
All spring-web and spring-webmvc Filter implementations have been
updated to participate in async request execution.
The open-session-in-view Filter and interceptors implementations in
spring-orm will be updated in a separate pull request.
Issue: SPR-8517
Previously depending on 1.5.10 in certain locations, which caused
NoClassDefFoundErrors in EhCacheCacheTests and other tests due to
mismatches between slf4j -api and -log4j12 versions.
With the exception of one transitive dependency via Hibernate 3.3.1.GA,
all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
Before this change, IDE settings generated via import-into-eclipse.sh
created a classpath dependency on slf4j-api version 1.6.1 and
slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE
resulted in a NoSuchMethodException.
build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However,
the hibernate-validator dependency in spring-context pulls in
slf4j-api version 1.6.1. The change ensures the version specified in
the build script variable is used consistently. Whether it should be
1.5.10 or 1.6.1 is a separate concern.
- Spring remains compatible against AJ version 1.6.8, but is now
compiling and testing against 1.6.12
- Encountered what appears to be an AJ bug introduced in 1.6.10: an
assertion in org.aspectj.weaver.UnresolvedType causes a false
negative failure when encountering org.springframework.io.Resource
arrays, e.g. "[org.springframework.io.Resource@xxx". This problem
has been reported to the AJ team and in the meantime, the recommended
workaround is to disable assertions either completely, or at least
selectively with
-disableassertions:org.aspectj.weaver.UnresolvedType
Issue: SPR-7989, SPR-9272
- Fix deprecation warnings about dynamic properties; favor use of
"extra properties extensions" per [1]
- Certain such deprecations are still issued due to violations within
the docbook-reference plugin. These will be fixed in an upcoming
revision of the plugin, at which point spring-framework will upgrade
to depend on it and these warnings will be eliminated
[1] http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Issue: SPR-9327
The new @MVC support classes select a HandlerMethodArgumentResolver
and a HandlerMethodReturnValueHandler statically, i.e. based on
the signature of the method, which means that a controller method
can't declare a more general return type like Object but actually
return a more specific one, e.g. String vs RedirectView, and
expect the right handler to be used.
The fix ensures that a HandlerMethodReturnValueHandler is selected
based on the actual return value type, which is something that was
supported with the old @MVC support classes. One consequence
of the change is the selected HandlerMethodReturnValueHandler can
no longer be cached but that matches the behavior of the old
@MVC support classes.
Issues: SPR-9218
Previously 'Content-Disposition' was passed to Part.getHeader(String).
However the Javadoc for that method specifies the header should be
case insensitive. Note that the JavaDoc in tomcat-servlet-api doesn't
mention this. It can only be found in the official api JavaDoc:
http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/
Issue: SPR-9149
Invalid Content-Type or Accept header values previously resulted in the
IllegalArgumentException getting propagated. After this change such
errors are detected and generally treated as a "no match", which
may for example result in a 406 in the case of the Accept header.
Issue: SPR-9148
A custom RequestCondition which can be provided by overriding methods
in RequestMappingHandlerMapping worked only for conditions that match
and did not return null (as it should have) for conditions that don't
match.
Issues: SPR-9134
Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no
substantive changes, but rather prepares for them by creating a clean
baseline. All internal references to 3.1 schemas (e.g. spring-tool) have
also been updated.
Before this change JibxMarshaller did not use the configured encoding
when unmarshalling XML. This caused issues when content being
unmarshalled was not encoded using the default encoding.
This commit fixes the issue by passing configured encoding to JiBX so
it gets used when unmarshalling instead of the default encoding.
Issue: SPR-7865
Use the preferred SessionFactoryImplementor#getDialect call as
opposed to the previous Dialect#getDialect approach which required
explicitly setting the 'hibernate.dialect' property.
Issue: SPR-7396
This change fixes a mistake made during an earlier sync with the 3.1.x
branch in which the new QueryTimeoutException class was accidentally
placed in spring-transaction instead of spring-tx.
Issue: SPR-7680
Before this change if FreeMarker Spring form macro was bound to a path
which contains square brackets, those brackets would also appear in id
of generated tag, making the id invalid.
As of this fix all FreeMarker Spring form macros generate tag with id
that does not contain square brackets.
Issue: SPR-8732
Before this fix MultipartResolver javadoc mentioned that there is only
one concrete implementation included in Spring. This was true as of
Spring 2.5 but Spring 3.1 added another one, Servlet 3.0 Part API based
implementation.
This fix changes MultipartResolver javadoc so that the other one,
StandardServletMultipartResolver implementation, gets also listed.
Changed javadoc mentions also as of which version does Spring bundle
two MultipartResolver implementations.
Issue: SPR-5984
Before this change bean scopes chapter in Spring reference documentation
had a note which mentioned that creating a scoped proxy for singleton-
or prototype-scoped beans will throw BeanCreationException.
This is no longer the case and this change removes the mentioned note.
Issue: SPR-7940
Prior to this commit, MutablePropertySources#get(String) would throw
IndexArrayOutOfBoundsException if the named property source does not
actually exist. This is a violation of the PropertySource#get contract
as described in its Javadoc.
The implementation now correctly checks for the existence of the named
property source, returning null if non-existent and otherwise returning
the associated PropertySource.
Other changes
- Rename PropertySourcesTests => MutablePropertySourcesTests
- Polish MutablePropertySourcesTests for style, formatting
- Refactor MutablePropertySources for consistency
Issue: SPR-9179
JDK7 changed its reflections API in order to resolve
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041784
In short, JDK 5 and 6 (wrongly) return GenericArrayTypes in certain
reflection scenarios, whereas JDK 7 changed this to return a normal
array type. For Jaxb2Marshaller, this meant that marshaling byte arrays
was not supported under JDK 7.
This change fixes that, so that Jaxb2Marhsaller supports marshalling
byte arrays again (under JDK 5, 6 or 7).
Due to changes made in commit 2fa87a71 for SPR-9118,
AbstractResource#contentLength would fall into an infinite loop unless
the method were overridden by a subclass (which it is in the majority of
use cases).
This commit:
- fixes the infinite recursion by refactoring to a while loop
- asserts that the value returned from #getInputStream is not null in
order to avoid NullPointerException
- tests both of the above
- adds Javadoc to the Resource interface to clearly document that the
contract for any implementation is that #getInputStream must not
return null
Issue: SPR-9161
- Rename customized .wrapper to default gradle/wrapper directory for
out of the box compatibility with STS Gradle tooling
- Add .settings/gradle directory to capture defaults when using STS
Gradle tooling to import projects
Prior to this change, before a bean is created by EhCacheFactoryBean,
its #getObjectType would return only an Ehcache interface. This caused
unwanted wiring issues as described in the related JIRA issue.
This fix makes use of EhCacheFactoryBean's configuration to determine
the specific Ehcache object type even before it's created, such that
the container is provided with as much information as possible when
resolving dependencies. Nevertheless, users are advised to code to
the Ehcache interface.
Issue: SPR-7843
ORA-00054 is already mapped to CannotAcquireLockException and is
described as
"resource busy and acquire with NOWAIT specified"
As pointed out in the associated JIRA issue, ORA-30006 is quite similar
being described as
"resource busy; acquire with WAIT timeout expired"
This commit maps ORA-30006 to CannotAcquireLockException as well.
Issue: SPR-9141
Changes in commit 41ade68b50 introduced
a regression causing all but the first location in the
@PropertySource#value array to be ignored during ${...} placeholder
resolution. This change ensures that all locations are processed and
replaced as expected.
Issue: SPR-9133, SPR-9127
* 3.1.x:
Warn re Environment construction and instance vars
Disallow empty @PropertySource(value = {})
Fix @PropertySource bug with multiple values
final preparations for 3.1.1 release
added "receive-timeout" attribute to "jms:listener-container" element
Previously, a user could specify an empty array of resource locations
to the @PropertySource annotation, which amounts to a meaningless no-op.
ConfigurationClassParser now throws IllegalArgumentException upon
encountering any such misconfiguration.
Prior to this commit, specifying a named @PropertySource with multiple
values would not work as expected. e.g.:
@PropertySource(
name = "ps",
value = { "classpath:a.properties", "classpath:b.properties" })
In this scenario, the implementation would register a.properties with
the name "ps", and subsequently register b.properties with the name
"ps", overwriting the entry for a.properties.
To fix this behavior, a CompositePropertySource type has been introduced
which accepts a single name and a set of PropertySource objects to
iterate over. ConfigurationClassParser's @PropertySource parsing routine
has been updated to use this composite approach when necessary, i.e.
when both an explicit name and more than one location have been
specified.
Note that if no explicit name is specified, the generated property
source names are enough to distinguish the instances and avoid
overwriting each other; this is why the composite wrapper is not used
in these cases.
Issue: SPR-9127
Rossen Stoyanchev
Chris Beams
Arjen Poutsma
Stevo Slavic
Mike Krumlauf
Phani Kandula