Annotation Interface EnableCaching
<cache:*>
XML namespace. To be used together
with @Configuration
classes as follows:
@Configuration @EnableCaching class AppConfig { @Bean MyService myService() { // configure and return a class having @Cacheable methods return new MyService(); } @Bean CacheManager cacheManager() { // configure and return an implementation of Spring's CacheManager SPI SimpleCacheManager cacheManager = new SimpleCacheManager(); cacheManager.setCaches(Set.of(new ConcurrentMapCache("default"))); return cacheManager; } }
For reference, the example above can be compared to the following Spring XML configuration:
<beans> <cache:annotation-driven/> <bean id="myService" class="com.foo.MyService"/> <bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager"> <property name="caches"> <set> <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"> <property name="name" value="default"/> </bean> </set> </property> </bean> </beans>In both of the scenarios above,
@EnableCaching
and
<cache:annotation-driven/>
are responsible for registering the necessary Spring
components that power annotation-driven cache management, such as the
CacheInterceptor
and the
proxy- or AspectJ-based advice that weaves the interceptor into the call stack when
@Cacheable
methods are invoked.
If the JSR-107 API and Spring's JCache implementation are present, the necessary
components to manage standard cache annotations are also registered. This creates the
proxy- or AspectJ-based advice that weaves the interceptor into the call stack when
methods annotated with CacheResult
, CachePut
, CacheRemove
or
CacheRemoveAll
are invoked.
A bean of type CacheManager
must be registered, as there is no reasonable default that the framework can
use as a convention. And whereas the <cache:annotation-driven>
element assumes
a bean named "cacheManager", @EnableCaching
searches for a cache
manager bean by type. Therefore, naming of the cache manager bean method is
not significant.
For those that wish to establish a more direct relationship between
@EnableCaching
and the exact cache manager bean to be used,
the CachingConfigurer
callback interface may be implemented.
Notice the @Override
-annotated methods below:
@Configuration @EnableCaching class AppConfig implements CachingConfigurer { @Bean MyService myService() { // configure and return a class having @Cacheable methods return new MyService(); } @Bean @Override CacheManager cacheManager() { // configure and return an implementation of Spring's CacheManager SPI SimpleCacheManager cacheManager = new SimpleCacheManager(); cacheManager.setCaches(Set.of(new ConcurrentMapCache("default"))); return cacheManager; } @Override KeyGenerator keyGenerator() { // configure and return an implementation of Spring's KeyGenerator SPI return new MyKeyGenerator(); } }This approach may be desirable simply because it is more explicit, or it may be necessary in order to distinguish between two
CacheManager
beans present in the
same container.
Notice also the keyGenerator
method in the example above. This allows for
customizing the strategy for cache key generation, per Spring's KeyGenerator
SPI. Normally,
@EnableCaching
will configure Spring's
SimpleKeyGenerator
for this purpose, but when implementing CachingConfigurer
, a custom key
generator can be specified.
CachingConfigurer
offers additional customization options:
see the CachingConfigurer
javadoc for further details.
The mode()
attribute controls how advice is applied: If the mode is
AdviceMode.PROXY
(the default), then the other attributes control the behavior
of the proxying. Please note that proxy mode allows for interception of calls through
the proxy only; local calls within the same class cannot get intercepted that way.
Note that if the mode() is set to AdviceMode.ASPECTJ
, then the
value of the proxyTargetClass()
attribute will be ignored. Note also that in
this case the spring-aspects
module JAR must be present on the classpath, with
compile-time weaving or load-time weaving applying the aspect to the affected classes.
There is no proxy involved in such a scenario; local calls will be intercepted as well.
- Since:
- 3.1
- Author:
- Chris Beams, Juergen Hoeller
- See Also:
-
Optional Element Summary
Modifier and TypeOptional ElementDescriptionIndicate how caching advice should be applied.int
Indicate the ordering of the execution of the caching advisor when multiple advices are applied at a specific joinpoint.boolean
Indicate whether subclass-based (CGLIB) proxies are to be created as opposed to standard Java interface-based proxies.
-
Element Details
-
proxyTargetClass
boolean proxyTargetClassIndicate whether subclass-based (CGLIB) proxies are to be created as opposed to standard Java interface-based proxies. The default isfalse
. Applicable only ifmode()
is set toAdviceMode.PROXY
.Note that setting this attribute to
true
will affect all Spring-managed beans requiring proxying, not just those marked with@Cacheable
. For example, other beans marked with Spring's@Transactional
annotation will be upgraded to subclass proxying at the same time. This approach has no negative impact in practice unless one is explicitly expecting one type of proxy vs another, e.g. in tests.- Default:
- false
-
mode
AdviceMode modeIndicate how caching advice should be applied.The default is
AdviceMode.PROXY
. Please note that proxy mode allows for interception of calls through the proxy only. Local calls within the same class cannot get intercepted that way; a caching annotation on such a method within a local call will be ignored since Spring's interceptor does not even kick in for such a runtime scenario. For a more advanced mode of interception, consider switching this toAdviceMode.ASPECTJ
.- Default:
- PROXY
-
order
int orderIndicate the ordering of the execution of the caching advisor when multiple advices are applied at a specific joinpoint.The default is
Ordered.LOWEST_PRECEDENCE
.- Default:
- 2147483647
-