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

[Kevin Pollet]

Hi,

On 25 October 2011 18:11, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Oct 24, 2011, at 4:58 PM, Kevin Pollet wrote:
>
> > 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"?
>
> +1
>
> Should be pretty straightfoward to implement for single type based keys as
> well.
>
>
I've opened ISPN-1491 <https://issues.jboss.org/browse/ISPN-1491> for
that. Any comments are welcome!


>  >
> >
> > --
> > 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
> >>
> >>
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111026/ed54898f/attachment.html