On Thursday 17 April 2014 10:47:32 Stephane Nicoll wrote:
> Unfortunately, it's not that easy.
>
> The Javadoc of "exceptionCacheName" states "If not specified no exception
> caching is done."[1]. This may sounds like a safe check: if
> exceptionCacheName on the annotation isn't set, then we simply don't call
> the CacheResolver. The problem is that you may specify a custom cache
> resolver (through the cache resolver factory) and that custom cache
> resolver may not care at all about the fact that the exceptionCacheName has
> a value or not (because its own logic doesn't require it).
>
> Right now, what the Spring framework support does is checking if the
> exceptionCacheName attribute is set. If it's not set, no exception cache
> resolver is associated with the operation[2] (down the road, if the
> resolver is not set, exception cache is disabled). Note that if
> exceptionCacheName is set and a *custom* resolver returns null, then
> exception caching is disabled as well which I personally think it's a good
> thing as it allows for more flexibility than the exception type filter at
> the annotation level.
So the question is:
Who should fulfill the annotations' contract, the CacheResolver or the "glue"
that calls it? Right?
> What I'd like to see is a less strict javadoc. To me, stating that "If not
> specified no exception caching is done" beats the purpose of having custom
> cache resolvers in the first place.
> Those can fully ignore the value of the
> annotation and resolve the exception cache name based on the method
> signature and/or runtime arguments.
Got your point!
It is also not consistent in itself, since cacheName is optional and has a reasonable
default. Its obvious that a developer wants to specify that exception caching
needs to be done, but does not want to specify a name for it, since it is
not needed at other places. So that's a bug.
> The problem with this is that you end
> up with a weird contract for CacheResolver as returning null for regular
> caches does not sound like it was the plan.
Some further weird thoughts on this:
If no caching is requested, you can return a Cache implementation that
is not caching at all. Where is written that "not caching" does mean there is
no cache instance? That's missing on the CacheResolver JavaDoc.....
> I understand that there is no perfect answer to this problem but the
> current Javadoc does not feel right.
+1
> Thoughts?
A possible answer is in the RI.
- A null cache means no caching
- the CacheResolver decides and only the CacheResolver
See getExceptionCache() here:
https://github.com/jsr107/RI/blob/master/cache-annotations-ri/cache-annotations-ri-common/src/main/java/org/jsr107/ri/annotations/AbstractCacheResultInterceptor.java
Still, there is something missing. How can a developer, say that we need exceptionCaching
without specifying a name? Since the name may be meaningless, I would opt for a convention,
for the case, it is indeed meaningless, e.g. exceptionCache="default" or exceptionCache="".
The JavaDoc needs to be clarified:
- CacheResolver: returns a Cache or null if no caching should occur
- At the annotation exceptionCache: Specifying this annotation means caching for exceptions
is requested. When a custom CacheResolver is in place the behaviour is determined by the
CacheResolver.
Sorry for my previous post on this, I was digging in the fog....
Cheers,