@Configuration
@EnableCaching
public class AppConfig {
        
Alternatively for XML configuration use the cache:annotation-driven element:
        
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:cache="http://www.springframework.org/schema/cache"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd">
    <cache:annotation-driven />
</beans>
        
Both the cache:annotation-driven element and @EnableCaching annotation allow various options to be specified that influence the way the
        caching behavior is added to the application through AOP. The configuration is intentionally similar
        with that of @Transactional:
        
Table 29.2. Cache annotation settings

            
XML Attribute
Annotation Attribute
Default
Description
cache-manager
N/A (See CachingConfigurer Javadoc)
cacheManager
Name of cache manager to use. Only required
                if the name of the cache manager is not
                cacheManager, as in the example
                above.
mode
mode
proxy
The default mode "proxy" processes annotated
                beans to be proxied using Spring's AOP framework (following
                proxy semantics, as discussed above, applying to method calls
                coming in through the proxy only). The alternative mode
                "aspectj" instead weaves the affected classes with Spring's
                AspectJ caching aspect, modifying the target class byte
                code to apply to any kind of method call. AspectJ weaving
                requires spring-aspects.jar in the classpath as well as
                load-time weaving (or compile-time weaving) enabled. (See
                the section called “Spring configuration” for details on how to set
                up load-time weaving.)
proxy-target-class
proxyTargetClass
false
Applies to proxy mode only. Controls what type of
                caching proxies are created for classes annotated with
                the @Cacheable or @CacheEvict annotations.
                If the proxy-target-class attribute is set
                to true, then class-based proxies are
                created. If proxy-target-class is
                false or if the attribute is omitted, then
                standard JDK interface-based proxies are created. (See Section 9.6, “Proxying mechanisms” for a detailed examination of the
                different proxy types.)
order
order
Ordered.LOWEST_PRECEDENCE
Defines the order of the cache advice that
                is applied to beans annotated with
                @Cacheable or @CacheEvict.
                (For more
                information about the rules related to ordering of AOP advice,
                see the section called “Advice ordering”.) No
                specified ordering means that the AOP subsystem determines the
                order of the advice.
        
<cache:annotation-driven/> only looks for
        @Cacheable/@CacheEvict on beans in the same
        application context it is defined in. This means that, if you put
        <cache:annotation-driven/> in a
        WebApplicationContext for a
        DispatcherServlet, it only checks for
        @Cacheable/@CacheEvict beans in your
        controllers, and not your services. See Section 17.2, “The DispatcherServlet” for more information.
        
Method visibility and
        @Cacheable/@CachePut/@CacheEvict
        
When using proxies, you should apply the
        @Cache* annotations only to
        methods with public visibility. If you do
        annotate protected, private or package-visible methods with these annotations,
        no error is raised, but the annotated method does not exhibit the configured
        caching settings. Consider the use of AspectJ (see below) if you
        need to annotate non-public methods as it changes the bytecode itself.
            
Spring recommends that you only annotate concrete classes (and
            methods of concrete classes) with the
            @Cache* annotation, as opposed
            to annotating interfaces. You certainly can place the
            @Cache* annotation on an
            interface (or an interface method), but this works only as you would
            expect it to if you are using interface-based proxies. The fact that
            Java annotations are not inherited from interfaces
            means that if you are using class-based proxies
            (proxy-target-class="true") or the weaving-based
            aspect (mode="aspectj"), then the caching
            settings are not recognized by the proxying and weaving
            infrastructure, and the object will not be wrapped in a
            caching proxy, which would be decidedly
            bad.
        
In proxy mode (which is the default), only external method calls
        coming in through the proxy are intercepted. This means that
        self-invocation, in effect, a method within the target object calling
        another method of the target object, will not lead to an actual
        caching at runtime even if the invoked method is marked with
        @Cacheable - considering using the aspectj mode in this case.
    
29.3.6 Using custom annotations

        
The caching abstraction allows one to use her own annotations to identify what method trigger cache population or eviction. This is quite handy as a template mechanism as it eliminates
        the need to duplicate cache annotation declarations (especially useful if the key or condition are specified) or if the foreign imports (org.springframework) are not allowed
        in your code base. Similar to the rest of the stereotype annotations, both @Cacheable and @CacheEvict
        can be used as meta-annotations, that is annotations that can annotate other annotations. To wit, let us replace a common @Cacheable declaration with our own, custom
        annotation:
        
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD})
@Cacheable(value=“books”, key="#isbn")
public @interface SlowService {
        
Above, we have defined our own SlowService annotation which itself is annotated with @Cacheable - now we can replace the following code:
        
@Cacheable(value="books", key="#isbn")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
        
with:
        
@SlowService
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
        
Even though @SlowService is not a Spring annotation, the container automatically picks up its declaration at runtime and understands its meaning. Note that as
        mentioned above, the annotation-driven behavior needs to be enabled.
    
29.4 Declarative XML-based caching

        
If annotations are not an option (no access to the sources or no external code), one can use XML for declarative caching. So instead of annotating the methods for caching, one specifies
        the target method and the caching directives externally (similar to the declarative transaction management advice). The previous example
        can be translated into:
        
<!-- the service we want to make cacheable -->
<bean id="bookService" class="x.y.service.DefaultBookService"/>
<!-- cache definitions -->
<cache:advice id="cacheAdvice" cache-manager="cacheManager">
    <cache:caching cache="books">
        <cache:cacheable method="findBook" key="#isbn"/>
        <cache:cache-evict method="loadBooks" all-entries="true"/>
    </cache:caching>
</cache:advice>
<!-- apply the cacheable behavior to all BookService interfaces -->
<aop:config>
    <aop:advisor advice-ref="cacheAdvice" pointcut="execution(* x.y.BookService.*(..))"/>
</aop:config>
// cache manager definition omitted
        
In the configuration above, the bookService is made cacheable. The caching semantics to apply are encapsulated in the cache:advice definition which
        instructs method findBooks to be used for putting data into the cache while method loadBooks for evicting data. Both definitions are working against the
        books cache.
        
The aop:config definition applies the cache advice to the appropriate points in the program by using the AspectJ pointcut expression (more information is available
        in Chapter 9, Aspect Oriented Programming with Spring). In the example above, all methods from the BookService are considered and the cache advice applied to them.
        
The declarative XML caching supports all of the annotation-based model so moving between the two should be fairly easy - further more both can be used inside the same application.
        The XML based approach does not touch the target code however it is inherently more verbose; when dealing with classes with overloaded methods that are targeted for caching, identifying the
        proper methods does take an extra effort since the method argument is not a good discriminator - in these cases, the AspectJ pointcut can be used to cherry pick the target
        methods and apply the appropriate caching functionality. However through XML, it is easier to apply a package/group/interface-wide caching (again due to the AspectJ pointcut) and to create
        template-like definitions (as we did in the example above by defining the target cache through the cache:definitions cache attribute).
    
29.5 Configuring the cache storage

    
Out of the box, the cache abstraction provides integration with two storages - one on top of the JDK ConcurrentMap and one
    for ehcache library. To use them, one needs to simply declare an appropriate CacheManager - an entity that controls and manages
    Caches and can be used to retrieve these for storage.
    
29.5.1 JDK ConcurrentMap-based Cache

        
The JDK-based Cache implementation resides under org.springframework.cache.concurrent package. It allows one to use 
        ConcurrentHashMap as a backing Cache store.
    
<!-- generic cache manager -->
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
    <property name="caches">
        <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="default"/>
        <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="books"/>
    </property>
</bean>
        
The snippet above uses the SimpleCacheManager to create a CacheManager for the two, nested Concurrent
        Cache implementations named default and books.
        Note that the names are configured directly for each cache.
        
As the cache is created by the application, it is bound to its lifecycle, making it suitable for basic use cases, tests or simple applications. The cache scales well and is very fast
        but it does not provide any management or persistence capabilities nor eviction contracts.
    
29.5.2 EhCache-based Cache

        
The EhCache implementation is located under org.springframework.cache.ehcache package. Again, to use it, one simply needs to declare the appropriate
        CacheManager:
        
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheCacheManager" p:cache-manager-ref="ehcache"/>
<!-- EhCache library setup -->
<bean id="ehcache" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" p:config-location="ehcache.xml"/>
        
This setup bootstraps ehcache library inside Spring IoC (through bean ehcache) which is then wired into the dedicated CacheManager
        implementation. Note the entire ehcache-specific configuration is read from the resource ehcache.xml.
    
29.5.3 GemFire-based Cache

        
GemFire is a memory-oriented/disk-backed, elastically scalable, continuously available, active (with built-in pattern-based subscription notifications),
        globally replicated database and provides fully-featured edge caching. For further information on how to use GemFire as a CacheManager (and more), please refer
        to the Spring GemFire reference documentation.
    
29.5.4 Dealing with caches without a backing store

        
Sometimes when switching environments or doing testing, one might have cache declarations without an actual backing cache configured. As this is an invalid configuration, at runtime an
        exception will be through since the caching infrastructure is unable to find a suitable store. In situations like this, rather then removing the cache declarations (which can prove tedious),
        one can wire in a simple, dummy cache that performs no caching - that is, forces the cached methods to be executed every time:
        
<bean id="cacheManager" class="org.springframework.cache.support.CompositeCacheManager">
    <property name="cacheManagers"><list>
        <ref bean="jdkCache"/>
        <ref bean="gemfireCache"/>
    </list></property>
    <property name="fallbackToNoOpCache" value="true"/>
</bean>
        
The CompositeCacheManager above chains multiple CacheManagers and additionally, through the fallbackToNoOpCache flag, adds a
        no op cache that for all the definitions not handled by the configured cache managers. That is, every cache definition not found in either jdkCache
        or gemfireCache (configured above) will be handled by the no op cache, which will not store any information causing the target method to be executed every time.
    
Clearly there are plenty of caching products out there that can be used as a backing store. To plug them in, one needs to provide a CacheManager and
    Cache implementation since unfortunately there is no available standard that we can use instead. This may sound harder then it is since in practice,
    the classes tend to be simple adapters that map the caching abstraction framework on top of the storage API as the ehcache classes can show.
    Most CacheManager classes can use the classes in org.springframework.cache.support package, such as AbstractCacheManager
    which takes care of the boiler-plate code leaving only the actual mapping to be completed. We hope that in time, the libraries that provide integration with Spring
    can fill in this small configuration gap.
    
29.7 How can I set the TTL/TTI/Eviction policy/XXX feature?

        
Directly through your cache provider. The cache abstraction is... well, an abstraction not a cache implementation. The solution you are using might support various data policies and different
        topologies which other solutions do not (take for example the JDK ConcurrentHashMap) - exposing that in the cache abstraction would be useless simply because there would