Prior to this commit, @Cacheable, @CacheEvict, @CachePut, and @Caching
could be used to create custom stereotype annotations with hardcoded
values for their attributes; however, it was not possible to create
composed annotations with attribute overrides.
This commit addresses this issue by refactoring
SpringCacheAnnotationParser to use the newly introduced
findAllMergedAnnotations() method in AnnotatedElementUtils. As a
result, @Cacheable, @CacheEvict, @CachePut, and @Caching can now be
used to create custom composed annotations with attribute overrides
configured via @AliasFor.
Issue: SPR-13475
Previously, a package private `@ManagedResource` annotated bean was
registered to the JMX domain even if any attempt to invoke an operation
on it will fail since it has to be public.
This commit validates that any `@ManagedResource` annotated bean is
public and throws an InvalidMetadataException otherwise. Note that the
actual bean type does not have to be public as long as the class
annotated with `@ManagedResource` in the hierarchy is pubic and no extra
operations or attributes are defined on the child.
Issue: SPR-14042
Previously, the generic type of a simple pojo event implementing
ResolvableTypeProvider wasn't detected properly. This commit fixes the
logic when the generic type is not provided to reuse what
PayloadApplicationEvent is already doing anyway.
Issue: SPR-14029
Previously, a ConfigurationClass created from AnnotationMetadata
and a ConfigurationClass created from a class would have subtly
different descriptions. Given a class named com.example.Foo, the
former’s description would be “com.example.Foo”, whereas the latter’s
description would be “class com.example.Foo”.
This commit updates ConfigurationClass to make the description
consistent, preferring the description without “class” in it.
Closes gh-970
This turned into the extraction of a common AbstractResourceBasedMessageSource base class which not only features addBasenames but also getBasenameSet and setCacheMillis.
Issue: SPR-10314
This change updates all cases where callbacks are invoked to catch and
suppress errors (since there is not match to do with and error from
a callback be it success or failure).
Also updated is the contract itself to clarify this and emphasize the
callbacks are really notifications for the outcome of the
ListenableFuture not the callbacks themselves.
Issue: SPR-13785
ConcurrentMapCacheManager and ConcurrentMapCache now support the
serialization of cache entries via a new `storeByValue` attribute. If it is
explicitly enabled, the cache value is first serialized and that content
is stored in the cache.
The net result is that any further change made on the object returned
from the annotated method is not applied on the copy held in the cache.
Issue: SPR-13758
Previously, if a `@Cacheable` method was accessed with the same key by
multiple threads, the underlying method was invoked several times instead
of blocking the threads while the value is computed. This scenario
typically affects users that enable caching to avoid calling a costly
method too often. When said method can be invoked by an arbitrary number
of clients on startup, caching has close to no effect.
This commit adds a new method on `Cache` that implements the read-through
pattern:
```
<T> T get(Object key, Callable<T> valueLoader);
```
If an entry for a given key is not found, the specified `Callable` is
invoked to "load" the value and cache it before returning it to the
caller. Because the entire operation is managed by the underlying cache
provider, it is much more easier to guarantee that the loader (e.g. the
annotated method) will be called only once in case of concurrent access.
A new `sync` attribute to the `@Cacheable` annotation has been addded.
When this flag is enabled, the caching abstraction invokes the new
`Cache` method define above. This new mode bring a set of limitations:
* It can't be combined with other cache operations
* Only one `@Cacheable` operation can be specified
* Only one cache is allowed
* `condition` and `unless` attribute are not supported
The rationale behind those limitations is that the underlying Cache is
taking care of the actual caching operation so we can't really apply
any SpEL or multiple caches handling there.
Issue: SPR-9254
