<html><head></head><body bgcolor="#FFFFFF"><div>If we didnt use any jsr107 annotations with this cache.<br><br>--<div>Pete Muir</div><div><a href="http://in.relation.to/Bloggers/Pete">http://in.relation.to/Bloggers/Pete</a></div></div><div><br>On 24 Oct 2011, at 16:38, Kevin Pollet <<a href="mailto:pollet.kevin@gmail.com">pollet.kevin@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>On 24 October 2011 16:30, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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?<br></blockquote><div><br></div><div>This is because the interceptors are defined like that in JSR-107.</div>
<div>I'm not sure to understand "If we used a general purpose cache, this wouldn't be a problem"?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
On 24 Oct 2011, at 16:25, Kevin Pollet wrote:<br>
<br>
> Hi Galder,<br>
><br>
> On 24 October 2011 15:15, Galder Zamarreño <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br>
> Pete/Kevin,<br>
><br>
> Looking at the Infinispan CDI quickstart, I see:<br>
><br>
> @GreetingCache<br>
> private Cache<CacheKey, String> cache;<br>
><br>
> The key that the user really uses here is String. So, could that be defined like this?<br>
><br>
> @GreetingCache<br>
> private Cache<String, String> cache;<br>
><br>
> Btw, I've just tried this and when using the key I get:<br>
><br>
> Caused by: java.lang.ClassCastException: org.infinispan.cdi.interceptor.DefaultCacheKey cannot be cast to java.lang.String<br>
><br>
> 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.<br>
><br>
> That's how it's defined in JSR-107 specification "All generated cache keys must implement the CacheKey interface."<br>
><br>
> 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.<br>
><br>
> Pete, Manik?<br>
><br>
><br>
> 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.<br>
> 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.<br>
><br>
> 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).<br>
><br>
><br>
> Cheers,<br>
> --<br>
> Galder Zamarreño<br>
> Sr. Software Engineer<br>
> Infinispan, JBoss Cache<br>
><br>
><br>
> --Kevin<br>
<br>
</div></div></blockquote></div><br>
</div></blockquote></body></html>