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

[Galder Zamarreño]

Pete/Kevin,

Looking at the Infinispan CDI quickstart, I see:

   @GreetingCache
   private Cache cache;

The key that the user really uses here is String. So, could that be defined 
like this?

   @GreetingCache
   private Cache 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. 

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.

Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Pete Muir]

I believe this is related to the use of JSR-107, it's not related to Infinispan 
(see the as7 quick start).

On 24 Oct 2011, at 15:15, Galder Zamarreño wrote:

> Pete/Kevin,
> 
> Looking at the Infinispan CDI quickstart, I see:
> 
>   @GreetingCache
>   private Cache cache;
> 
> The key that the user really uses here is String. So, could that be defined 
> like this?
> 
>   @GreetingCache
>   private Cache 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. 
> 
> 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.
> 
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Kevin Pollet]

Hi Galder,

On 24 October 2011 15:15, Galder Zamarreño  wrote:

> Pete/Kevin,
>
> Looking at the Infinispan CDI quickstart, I see:
>
>   @GreetingCache
>   private Cache cache;
>
> The key that the user really uses here is String. So, could that be defined
> like this?
>
>   @GreetingCache
>   private Cache 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Pete Muir]

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?

On 24 Oct 2011, at 16:25, Kevin Pollet wrote:

> Hi Galder,
> 
> On 24 October 2011 15:15, Galder Zamarreño  wrote:
> Pete/Kevin,
> 
> Looking at the Infinispan CDI quickstart, I see:
> 
>   @GreetingCache
>   private Cache cache;
> 
> The key that the user really uses here is String. So, could that be defined 
> like this?
> 
>   @GreetingCache
>   private Cache 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Kevin Pollet]

On 24 October 2011 16:30, Pete Muir  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  wrote:
> > Pete/Kevin,
> >
> > Looking at the Infinispan CDI quickstart, I see:
> >
> >   @GreetingCache
> >   private Cache cache;
> >
> > The key that the user really uses here is String. So, could that be
> defined like this?
> >
> >   @GreetingCache
> >   private Cache 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Peter Muir]

If we didnt use any jsr107 annotations with this cache.

--
Pete Muir
http://in.relation.to/Bloggers/Pete

On 24 Oct 2011, at 16:38, Kevin Pollet  wrote:

> On 24 October 2011 16:30, Pete Muir  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  wrote:
> > Pete/Kevin,
> >
> > Looking at the Infinispan CDI quickstart, I see:
> >
> >   @GreetingCache
> >   private Cache cache;
> >
> > The key that the user really uses here is String. So, could that be defined 
> > like this?
> >
> >   @GreetingCache
> >   private Cache 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Kevin Pollet]

On 24 October 2011 16:51, Peter Muir  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
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  wrote:
>
> On 24 October 2011 16:30, Pete Muir  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  wrote:
>> > Pete/Kevin,
>> >
>> > Looking at the Infinispan CDI quickstart, I see:
>> >
>> >   @GreetingCache
>> >   private Cache cache;
>> >
>> > The key that the user really uses here is String. So, could that be
>> defined like this?
>> >
>> >   @GreetingCache
>> >   private Cache 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Galder Zamarreño]

On Oct 24, 2011, at 4:58 PM, Kevin Pollet wrote:

> On 24 October 2011 16:51, Peter Muir  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 
> 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.

>  
>  
> --
> Pete Muir
> http://in.relation.to/Bloggers/Pete
> 
> On 24 Oct 2011, at 16:38, Kevin Pollet  wrote:
> 
>> On 24 October 2011 16:30, Pete Muir  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  wrote:
>> > Pete/Kevin,
>> >
>> > Looking at the Infinispan CDI quickstart, I see:
>> >
>> >   @GreetingCache
>> >   private Cache cache;
>> >
>> > The key that the user really uses here is String. So, could that be 
>> > defined like this?
>> >
>> >   @GreetingCache
>> >   private Cache 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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

[Kevin Pollet]

Hi,

On 25 October 2011 18:11, Galder Zamarreño  wrote:

>
> On Oct 24, 2011, at 4:58 PM, Kevin Pollet wrote:
>
> > On 24 October 2011 16:51, Peter Muir  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 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  for
that. Any comments are welcome!


>  >
> >
> > --
> > Pete Muir
> > http://in.relation.to/Bloggers/Pete
> >
> > On 24 Oct 2011, at 16:38, Kevin Pollet  wrote:
> >
> >> On 24 October 2011 16:30, Pete Muir  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  wrote:
> >> > Pete/Kevin,
> >> >
> >> > Looking at the Infinispan CDI quickstart, I see:
> >> >
> >> >   @GreetingCache
> >> >   private Cache cache;
> >> >
> >> > The key that the user really uses here is String. So, could that be
> defined like this?
> >> >
> >> >   @GreetingCache
> >> >   private Cache 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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--Kevin
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev