This commit adds support for @Priority to filter multiple candidates
for autowiring. When multiple candidates are available for a given
bean, the bean annotated with @Primary is used. If none exists, the
one with the higher value for the @Priority annotation is used. If
two beans have the same priority a NoUniqueBeanDefinitionException
is thrown, just as if two beans are annotated with @Primary.
The underlying code for #getBean and #resolveDependency has been
merged as this feature is available for both dependency injection
and bean lookup by type.
Issue: SPR-10548
Added tests checking the behaviour of autowiring by type when the @Primary
annotation is present on the class. Fixed also some inconsistencies in the
code.
Prior to this commit, common cache operation settings had to be
repeated for every operation: cache name(s), custom cache manager
and custom key manager.
This commit introduces the @CacheConfig annotation to bet set at
class-level (either directly or as a meta-annotation). As the cache
name(s) can be rationalized there, the "value" of the various
annotations are no longer mandatory.
CacheAnnotationParser has an API breakage to be able to retrieve
information at class-level.
Issue: SPR-11316
It is now possible to specify the CacheManager to use per operation.
The related cache annotation now has an extra attribute that defines
the name of the CacheManager bean to use. The cache manager that
was previously used is therefore a 'default' cache manager (i.e. the
one to use if no custom cache manager has been set on the operation).
Issue: SPR-8696
This commit adds an extra parameter to the base @Cache method
annotations: keyGenerator. This parameter holds the name of the
KeyGenerator bean to use to compute the key for that specific
caching endpoint.
This gives therefore a third way to customize the key. These are:
1. Default KeyGenerator (global for all endpoints)
2. The 'key' attribute of the annotation, giving the SpEL expression to use
3. The 'keyGenerator' attribute of the annotation
The annotation attributes are therefore exclusive. Trying to specify
them both will result in an IllegalStateException.
The KeyGenerator to use for a given operation is cached on startup
so that multiple calls to it does not resolve the instance to use over and
over again.
Issue: SPR-10629
This commit ensures that QuartzSupportTests and its related
configuration are compatible with Quartz 2.1.7.
- Test jobs are now durable where required.
- Deleted legacy tests that attempted to use a Runnable instead of a
Job as a jobClass for a JobDetail.
- Replaced quartz-hsql.sql with current version for Quartz 2.1.7.
Issue: SPR-11630
To simplify common use cases, this commit introduces a new
execute(DataSource) method in ResourceDatabasePopulator that complements
the existing populate(Connection) method.
Issue: SPR-11629
Prior to this commit, if multiple test methods were executed in a
subclass of AbstractTestNGSpringContextTests annotated with
@WebAppConfiguration, then injected Servlet API mocks would only
reference the mocks created for the first test method. Subsequent test
methods could therefore never reference the current mocks, and there
was a discrepancy between the state of the injected mocks and the mock
set in the RequestContextHolder.
This commit addresses this issue by ensuring that dependencies
(including updated mocks) are injected into the test instance before
the next test method if the ServletTestExecutionListener resets the
request attributes in RequestContextHolder.
Issue: SPR-11626
Previously, the use of Assume.group(CUSTOM_COMPILATION) in
AbstractJasperReportsTests excluded all JR tests when executing in the
IDE (e.g., Eclipse). This commit executes the assumption only where
necessary.
Proactively notify all active WebSocket sessions when a shutdown is
progress. Sessions then can ignore further attempts to send messages
and also stop stop trying to flush messages right away.
Although the need to map the ASYNC dispatcher type to a Filter was
already mentioned, it wasn't very prominent and can be quite critical
in some cases. This change addresses that.
Issue: SPR-10440
This reverts commit 3474afb165.
Unfortunately this change is likely to cause issues for applications
that use regular expressions in a URI variable. I think we will have
to leave at: if there are any dots in the last segment of the
request path, regardless of whether they're in a URI var or not,
the suffix pattern match is off.
Issue: SPR-11532
Improved the SAX to StAX (and vice-versa) bridge exposed via StaxUtils.
The old integration had some issues with namespace declaration
attributes, brought to light in a XMLUnit upgrade.
Issue: SPR-11549
Changes introduced in conjunction with issue SPR-11475 altered the
behavior of StandardAnnotationMetadata such that annotations could be
detected on superclasses, specifically in the case where the
AnnotatedElementUtils.getAllAnnotationAttributes() method is invoked to
obtain multiple annotations of the same type (on the lowest level in the
class hierarchy), as is the case for @Profile and @Conditional.
This commit partially reverts these changes as follows:
- All methods in AnnotatedElementUtils now set the
traverseClassHierarchy to false, thereby effectively reverting the
changes made in commit 1d30bf83a0.
Note, however, that the changes made to AnnotationUtils remain in
place.
- Introduced tests in AnnotationMetadataTests that verify behavior
present in Spring Framework 4.0.2 and earlier.
- Updated tests in AnnotatedElementUtilsTests so that they pass against
the reverted changes (i.e., align with the behavior present in Spring
Framework 4.0.2 and earlier).
- Refined Javadoc in AnnotationMetadata with regard to annotations
being "present" vs. "defined".
- Refined Javadoc in AnnotatedTypeMetadata.
Issue: SPR-11475, SPR-11595
This commit validates that the payload type of the message is
assignable to the one declared in the method signature. If that
is not the case, a meaningful exception message is thrown with
the types mismatch.
Prior to this commit, only the Message interface could be defined
in the method signature: it is now possible to define a sub-class
of Message if necessary which will match as long as the Message
parameter is assignable to that type.
Issue: SPR-11584
