Provide a @CacheConfig annotation to share class-level customizations [SPR-11316]

[spring-projects-issues]

Stéphane Nicoll opened SPR-11316 and commented

#13338 and #15257 have introduced two customisations related to the cache operation: cache manager and key generator.

The feature is tedious and error-prone as these customisations have to be set for each and every operation. The idea here is to introduce a new annotation @CacheConfig that could be set at class-level only and that would gather those customisations as well as the default cache name. Something like:

@CacheConfig(cacheManager = "myCacheManager")
public class FooRepository {

  @Cacheable("test)
  public void getFoo(String id) { ... }

}

If a caching operation specifies its own cache manager, key generator or cache names, that one is used instead of the default.

In other words, this is about giving 3 levels of customisation:

1. General level (the global "cacheManager", "keyGenerator"; not available for cache names)
2. Class level (through the @CacheConfig annotation)
3. Operation level (through the explicit caching operation such as @Cacheable)

---

Issue Links:

• Introduce qualifier in @Cacheable for cache manager name [SPR-8696] #13338 Introduce qualifier in @Cacheable for cache manager name
• Be able to specify custom key generators on a per-cache basis [SPR-10629] #15257 Be able to specify custom key generators on a per-cache basis
• Apply CacheResolver to Spring's caching abstraction [SPR-11490] #16115 Apply CacheResolver to Spring's caching abstraction

Referenced from: commits 2b89c1a, 3c28301

0 votes, 6 watchers

[spring-projects-issues]

Juergen Hoeller commented

This generally makes sense to me.

However, we should research our JCache 1.0 alignment before making any decisions here, since they have a similar mechanism in place. We don't need to do it exactly their way but we should at least try to avoid accidental differences in style and semantics. And for 4.1, we're considering actual support for the standard JCache annotations as well, so it might also ease our common implementation effort for both kinds of annotations then.

Juergen

[spring-projects-issues]

Stéphane Nicoll commented

I have one candidate implementation here locally that provides this feature. I had to break the API to incorporate the scanning of the class-level annotation: CacheAnnotationParser has now two methods instead of a single one dealing with an AnnotatedElement: one taking a Method and one taking a Class.

This actually corresponds to what we're doing internally in AnnotationCacheOperationSource.

As we allow to define the cache name(s) at the class level now, all annotations have a default value of an empty array instead of requiring it. Added an explicit check to validate the content of the CacheOperation.

The CacheConfig can also be set as a meta-annotation but there's no merging facilities: if two annotations are detected on the same class, an IllegalStateException is thrown.

[spring-projects-issues]

Stéphane Nicoll commented

This is now available in master and in the next 4.1.0.BUILD-SNAPSHOT.

I could not work around an API breakage here: CacheAnnotationParser has now two methods: one taking a Method and one taking a Class so that we can read the shared cache config, if any.

Also, the code is now relying on AnnotationUtils.getAnnotation so that it supports the use of meta-annotation and returns the most specific annotation instead of throwing an exception.