Could @KeyGenerator take directly the Class<? extends CacheKeyGenerator> of our custom CacheKeyGenerator, instead of its "full.className"?

[Christophe Maillard]

Hello there,

I developed my own CacheKeyGenerator, but the basePackage of my application will possibly change a lot.

What I tried yet, is to use @KeyGenerator(name = "${application.basePackage}.dao.support.DaoCacheKeyGenerator"), and to use the Maven Resources Plugin to filter the ${application.basePackage} value, but I can't make it work. Would it be possible to be able to give directly the Class<? extends CacheKeyGenerator> of our custom CacheKeyGenerator instead of its full class name? For example, it would be great to be able to write: @KeyGenerator(clazz = DaoCacheKeyGenerator.class).

You would then just need to modify your annotation as follow, and give a priority order to the name and the clazz attributes (e.g. if both have values, use the name one):

@Target( { ElementType.ANNOTATION_TYPE } )

@Retention(RetentionPolicy.RUNTIME)

@Inherited

@Documented

public @interface KeyGenerator {

    String name();

    Class<? extends CacheKeyGenerator> clazz();

    Property[] properties() default {};

    

}

Waiting for your opinion ;)

Chris

[Nicholas Blair]

The proposed change will run into a compiler warning, since CacheKeyGenerator is a parameterized type. We'd also have to come up with a sensible default value; without one "clazz()" would be interpreted as a required field on the annotation (and null isn't acceptable, has to be a class literal).

Have you tried changing the default cache key generator?

The annotation-driven element supports an attribute named "default-cache-key-generator" that allows you to provide a reference to the CacheKeyGenerator implementation that should be used by default:

<ehcache:annotation-driven default-cache-key-generator="myCustomKeyGenerator"/>

<bean id="myCustomKeyGenerator" class="...DaoCacheKeyGenerator"/>

Then you wouldn't have to include the @KeyGenerator config in your @Cacheable annotations, you would only have to maintain the full classname to your custom key generator in the spring config.

Would that be an acceptable workaround?

[Christophe Maillard]

Many thanks Nicholas! It's a shame I didn't see this attribute before, because it's exactly what I needed ;)