[infinispan-dev] Abstracting javax.cache.annotation.CacheKey away from the user?

[Kevin Pollet]

On 24 October 2011 16:51, Peter Muir <pmuir at redhat.com> wrote:

> If we didnt use any jsr107 annotations with this cache.
>

Without any jsr107 annotations it works fine :-)

I've just got an idea, what do you think about providing a SingleCacheKey<T>
interface (which extends CacheKey) used when only one value is used as a
key?

This interface could provide an additionnal method "T getValue"?


>
>
--
> Pete Muir
> http://in.relation.to/Bloggers/Pete
>
> On 24 Oct 2011, at 16:38, Kevin Pollet <pollet.kevin at gmail.com> wrote:
>
> On 24 October 2011 16:30, Pete Muir <pmuir at redhat.com> wrote:
>
>> This is just because you are interacting with the JSR-107 managed cache.
>> If we used a general purpose cache, this wouldn't be a problem right?
>>
>
> This is because the interceptors are defined like that in JSR-107.
> I'm not sure to understand "If we used a general purpose cache, this
> wouldn't be a problem"?
>
>
>>
>> On 24 Oct 2011, at 16:25, Kevin Pollet wrote:
>>
>> > Hi Galder,
>> >
>> > On 24 October 2011 15:15, Galder Zamarreño <galder at 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 contract 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111024/667a0c7d/attachment.html