- Deleted empty AbstractWebSocketClientTests class.
- AbstractServletHandlerMethodTests and AbstractHttpRequestTests are
now actually declared as abstract.
- The following classes are not abstract but currently have an
"Abstract" prefix and therefore get ignored by the Gradle build.
This commit renames each of these by deleting the "Abstract" prefix.
- AbstractFlashMapManagerTests
- AbstractMappingContentNegotiationStrategyTests
- AbstractSockJsServiceTests
- AbstractWebSocketHandlerRegistrationTests
Prior to this commit, an array argument was not handled properly in
SimpleKey#equals and SimpleKey#hashCode. As a result, two method
invocations with the same array argument lead to two different keys
and therefore two different entries in the cache.
This commit uses deepEquals and deepHashCode to properly handle
methods that have arguments that are array types.
Issue: SPR-11505
Prior to this commit, the test results for JUnit tests overwrote the
results for TestNG tests in the HTML test report generated by the
Gradle build.
This commit addresses this problem by introducing a new
'aggregateTestReports' task in the spring-test module and making the
'check' task depend on it.
To see aggregated reports in the spring-test module, execute either
`gradle build` or `gradle check`. Executing `gradle test` alone will
not trigger test report aggregation.
Issue: SPR-11509
The Servlet API does not provide notifications when a client
disconnects, see see https://java.net/jira/browse/SERVLET_SPEC-44.
Therefore network IO failures may occur simply because a client has
gone away. Before this change that could fill logs with unnecessary
stack traces.
After this change we make a best effort to identify such network
failures, on a per-server basis (tested with Jetty, Tomcat, Glassfish,
and WildFly), and log them under a separate log category.
A simple one-line message is logged at DEBUG level (i.e. no stack trace)
while a full stack trace is shown at TRACE level.
Issue: SPR-11438
The breakout box named "Constructor-based or setter-based DI?" in the
reference manual currently recommends the use of setter injection.
This commit refines this text to align with current best practices and
now favors constructor injection over setter injection.
Issue: SPR-11459
Allow Jaxb2RootElementHttpMessageConverter subclasses to customize
the {@link Marshaller} and the {@link Unmarshaller} created by the
message converter.
Issue: SPR-11488
Prior to this commit, one had to provide her own
RequestMappingHandlerMapping instance (i.e extend
WebMvcConfigurationSupport and override the requestMappingHandlerMapping
method) in order to customize path matching properties on that bean.
Since SPR-10163, XML config users can do that using the
<mvc:path-matching/> XML tag. This commit adds the same feature to MVC
Java config with a PathMatchConfigurer.
Issue: SPR-11486
Before this change CompositeMessageConverter had a ContentTypeResolver
field that was in turn set on all contained converters.
After this change that field is removed and effectively
CompositeMessageConverter is a simple container of other converters.
Each converter in turn must have been configured with a
ContentTypeResolver.
Doing so means it is less likely to have unexpected consequences when
configuring converters, the ContentTypeResolver set in the composite
converter overriding the one configured in a contained converter.
Also commit 676ce6 added default ContentTypeResolver initialization
to AbstractMessageConverter, which ensures that converters are still
straight forward to configure.
Issue: SPR-11462
Previously AbstractMessageConverter did not have a ContentTypeResolver
configured by default. However the Java config and XML namespace in
spring-messaging and spring-websocket always configured one.
This change ensures every AbstractMessageConverter is configured with an
instance of DefaultContentTypeResolver by default. This makes sense since
all the resolver does is make an attempt to find a content type to use
for matching. If it can't it returns null and it's up to the converter
to decide whether it can convert or not.
Issue: SPR-11462
AbstractMessageConverter now supports a strictContentTypeMatching mode
in which the content type of a message must be resolved to a (non-null)
value that matches one of the configured supported MIME types in order
for the converter to be used.
Issue: SPR-11463
This commit:
* adds a reference to the Spring Code Style wiki page in the main
CONTRIBUTING document
* updates the link to the Spring team in README
* adds a note regarding Intellij IDEA 13 issues
The previous commit introduced a dependency on
Class.getDeclaredAnnotation() which is a Java 8 API.
This commit refactors AnnotationUtils.findAnnotation(Class, Class, Set)
to use Class.getAnnotation() in conjunction with
isAnnotationDeclaredLocally() in order to achieve the same desired
behavior.
Issue: SPR-11475
Prior to this commit, the implementations of findAnnotation() in
AnnotationUtils and getAnnotationAttributes() in AnnotatedElementUtils
favored inherited annotations and inherited composed annotations over
composed annotations that are declared closer to the starting class
passed to these methods.
This commit addresses this issue as follows:
- Refactored AnnotationUtils to use getDeclaredAnnotation() and
getDeclaredAnnotations() instead of getAnnotation() and
getAnnotations() where appropriate.
- AnnotatedElementUtils.doProcess() supports a traverseClassHierarchy
flag to control whether the class hierarchy should be traversed,
using getDeclaredAnnotations() instead of getAnnotations() if the
flag is true.
- Overhauled Javadoc in AnnotatedElementUtils.
Issue: SPR-11475
Juergen Hoeller
Sam Brannen
Rossen Stoyanchev
Stephane Nicoll
Craig Andrews
Marcin Mielnicki
Brian Clozel
Oliver Gierke
Sebastien Deleuze