Re: [infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?
Hi Galder,
On 24 October 2011 15:15, Galder Zamarreño <galder(a)redhat.com> wrote:
Pete/Kevin,
Looking at the Infinispan CDI quickstart, I see:
@GreetingCache
private Cache<CacheKey, String> cache;
The key that the user really uses here is String. So, could that be defined
like this?
@GreetingCache
private Cache<String, String> cache;
Btw, I've just tried this and when using the key I get:
Caused by: java.lang.ClassCastException:
org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to
java.lang.String
Are we forcing the user to dephicer what's in CacheKey? Related to this,
looking at org.infinispan.cdi.interceptor.DefaultCacheKey I see no way to
retrieve individual elements of a key.
That's how it's defined in JSR-107 specification "All generated cache keys
must implement the CacheKey interface."
If you look at the CacheKey
<https://github.com/kevinpollet/jsr107spec/blob/master/src/main/java/javax...
there is no methods defined to retrieve the content of the key. Here we
could provide our own methods but the user will be implementation dependent.
Maybe you could raise this point on JSR-107 mailing list, an unwrap method
could be defined in the *CacheKey *contract to use specific implementation
features.
Pete, Manik?
My point here is whether we can avoid leaking
javax.cache.annotation.CacheKey to the user cos it can do little with it
without being able to get its contents.
I see there;s a way to define a custom key, but that should not be necessary
for a simple key based on a String for example.
I'm not sure we can avoid the use of CacheKey since it's defined like that
in the spec. As said before we can provide at least our own methods in
the *DefaultCacheKey
*implementation (open an issue and I'll do it).
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
--Kevin
Attachments:
- attachment.html (text/html — 2.9 KB)