org.springframework.cache.annotation
Annotation Type EnableCaching

@Target(value=TYPE)
@Retention(value=RUNTIME)
@Documented
@Import(value=CachingConfigurationSelector.class)
public @interface EnableCaching

Enables Spring's annotation-driven cache management capability, similar to the support found in Spring's <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.addCaches(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.

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 implements clause and the @Override-annotated methods below:

 @Configuration
 @EnableCaching
 public class AppConfig implements CachingConfigurer {
     @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.addCaches(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 DefaultKeyGenerator for this purpose, but when implementing CachingConfigurer, a key generator must be provided explicitly. Return new DefaultKeyGenerator() from this method if no customization is necessary. 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.

Since:

3.1

Author:

Chris Beams

See Also:

CachingConfigurer, CachingConfigurationSelector, ProxyCachingConfiguration, AspectJCachingConfiguration

Optional Element Summary

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.

proxyTargetClass

public abstract boolean proxyTargetClass

Indicate whether subclass-based (CGLIB) proxies are to be created as opposed to standard Java interface-based proxies. The default is 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.

Default:

false

mode

public abstract AdviceMode mode

Indicate how caching advice should be applied. The default is AdviceMode.PROXY.

See Also:

AdviceMode

Default:

org.springframework.context.annotation.AdviceMode.PROXY

order

public abstract int order

Indicate 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