@Target(value=TYPE) @Retention(value=RUNTIME) @Documented @Import(value=CachingConfigurationSelector.class) public @interface EnableCaching
<cache:*> XML namespace. To be used together
with @Configuration
classes as follows:
@Configuration
@EnableCaching
public class AppConfig {
@Bean
public MyService myService() {
// configure and return a class having @Cacheable methods
return new MyService();
}
@Bean
public CacheManager cacheManager() {
// configure and return an implementation of Spring's CacheManager SPI
SimpleCacheManager cacheManager = new SimpleCacheManager();
cacheManager.setCaches(Arrays.asList(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
public class AppConfig extends CachingConfigurerSupport {
@Bean
public MyService myService() {
// configure and return a class having @Cacheable methods
return new MyService();
}
@Bean
@Override
public CacheManager cacheManager() {
// configure and return an implementation of Spring's CacheManager SPI
SimpleCacheManager cacheManager = new SimpleCacheManager();
cacheManager.setCaches(Arrays.asList(new ConcurrentMapCache("default")));
return cacheManager;
}
@Bean
@Override
public 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 key generator
must be provided explicitly. Return null or new SimpleKeyGenerator()
from this method if no customization is necessary.
CachingConfigurer offers additional customization options: it is recommended
to extend from CachingConfigurerSupport that provides a default implementation for all methods which
can be useful if you do not need to customize everything. See 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 such as
proxyTargetClass() control the behavior of the proxying.
If the mode() is set to AdviceMode.ASPECTJ, then the
proxyTargetClass() attribute is obsolete. Note also that in this case the
spring-aspects module JAR must be present on the classpath.
CachingConfigurer,
CachingConfigurationSelector,
ProxyCachingConfiguration,
org.springframework.cache.aspectj.AspectJCachingConfiguration| Modifier and Type | Optional Element and Description |
|---|---|
AdviceMode |
mode
Indicate how caching advice should be applied.
|
int |
order
Indicate the ordering of the execution of the caching advisor
when multiple advices are applied at a specific joinpoint.
|
boolean |
proxyTargetClass
Indicate whether subclass-based (CGLIB) proxies are to be created as opposed
to standard Java interface-based proxies.
|
public abstract boolean proxyTargetClass
false.
Applicable only if mode() is set to AdviceMode.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.
public abstract AdviceMode mode
AdviceMode.PROXY.AdviceMode