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
Ant 1.9.2 is packaged with Gradle since release 1.10. Since the Spring
Framework build now uses Gradle 1.11, there is no longer a need for the
"javac1.7" build compiler work-around for the spring-oxm module.
This commit introduces a new isInJavaLangAnnotationPackage(Annotation)
method in AnnotationUtils. This method is now used in AnnotationUtils,
AnnotatedElementUtils, and MetaAnnotationUtils to ensure that search
algorithms do no search for meta-annotations on annotations in the
"java.lang.annotation" package.
The following are some empirical results from this change:
- The number of times that the findAnnotation(Class,Class,Set) method in
AnnotationUtils is recursively invoked while executing
AnnotationUtilsTests drops from 51 to 29.
- The number of times that the process(AnnotatedElement) method in
AnnotationUtils.AnnotationCollector is recursively invoked while
executing AnnotationUtilsTests.getRepeatableFromMethod() drops
from 16 to 2.
- The number of times that the doProcess() method in
AnnotatedElementUtils is recursively invoked while executing the
"getAnnotationAttributes() On MetaCycleAnnotatedClass with missing
target meta-annotation" test in AnnotatedElementUtilsTests drops
from 23 to 5.
- The number of times that the findAnnotationDescriptor(Class,Set,Class)
method in MetaAnnotationUtils is recursively invoked while executing
the "findAnnotationDescriptor() on MetaCycleAnnotatedClass with
missing target meta-annotation" test in MetaAnnotationUtilsTests drops
from 16 to 8.
Issue: SPR-11483
Clarify ability to use @MessageMapping methods on both @Controller as
well as @RestController.
Add section on configuring connections (including credentials) to the
message broker and clarify the use of the login/passcode headerers of
the STOMP CONNECT frame.
Add note on when to add the reactor-tcp dependency.
Issue: SPR-11464, SPR-11436, SPR-11449
Prior to this commit, the following methods in ContextLoaderUtils
treated a composed @ContextConfiguration annotation (i.e., a custom
annotation that is meta-annotated with @ContextConfiguration) as the
"declaring class" instead of the actual test class.
- resolveContextConfigurationAttributes()
- resolveContextHierarchyAttributes()
As a consequence, if @ContextConfiguration is used as a
meta-annotation, the meta-annotated class is stored as the
"declaringClass" in ContextConfigurationAttributes. Thus, when a
ContextLoader (or SmartContextLoader) attempts to detect default
resource locations or configuration classes, it does so for the
composed annotation class instead of for the declaring test class.
This commit ensures that ContextLoaders are supplied the declaring test
class instead of the composed annotation class in such use cases.
Issue: SPR-11455
Before this change tests on the CI server showed the following message:
Store limit is 102400 mb, whilst the data directory:
/opt/.../KahaDB only has 74810 mb of usable space
This change turns off store persistence and also explicitly sets the
limit on memory usage.
Prior to this commit, the findAnnotationDescriptor() and
findAnnotationDescriptorForTypes() methods in MetaAnnotationUtils only
supported a single level of meta-annotations. In particular, this kept
the following annotations from being used as meta-annotations on
meta-annotations:
- @ContextConfiguration
- @ContextHierarchy
- @ActiveProfiles
- @TestExecutionListeners
This commit alters the search algorithms used in MetaAnnotationUtils so
that arbitrary levels of meta-annotations are now supported for the
aforementioned test-related annotations.
Issue: SPR-11470
Prior to this commit, if @ActiveProfiles were used as a meta-annotation
on a composed annotation, then the composed annotation's class would be
passed to the ActiveProfilesResolver.resolve() method instead of the
test class, which breaks the contract for ActiveProfilesResolver.
This commit addresses this issue by ensuring that the actual test class
is always passed to ActiveProfilesResolver.resolve().
Issue: SPR-11467
Prior to this commit, AnnotationUtils.findAnnotation(Class, Class)
claimed to recursively search through annotations; however, only one
level of annotations was supported by the algorithm.
This commit alters the search algorithm so that nested meta-annotations
(i.e., meta-annotations on meta-annotations) are also supported.
Issue: SPR-11448
Update ConcurrentReferenceHashMap to protect against references that
have been garbage collected but for some reason do not appear as a
`pollForPurge` result.
Also added purgeUnreferencedEntries() method to allow for programmatic
cleanup.
Issue: SPR-11440
Prior to this commit, one couldn't set the virtualHost property on
StompBrokerRelayMessageHandler via JavaConfig, since
StompBrokerRelayRegistration's API didn't offer that possibility.
This commit adds a new method in StompBrokerRelayRegistration's fluent
API to set the virtualHost used by StompBrokerRelayMessageHandler.
Note: this property is already configurable via xml config.
Issue: SPR-11433
Juergen Hoeller
Rossen Stoyanchev
Sebastien Deleuze
Brian Clozel
Sam Brannen
Phillip Webb
Andy Wilkinson
Konstantin Petrukhnov
Spring Buildmaster