Hello, I was quite surprised to see that cache.getCacheManager() doesn't return the CacheManager but a CacheContainer, which I then need to cast to an EmbeddedCacheManager.

Shouldn't the signature of the interface be updated to return a CacheManager ?

The methods exposed by a CacheContainer are rather useless, especially when returned from a cache instance as the only two I could use are getCache() and getCache(String cacheName); a use case to explain it better: ((EmbeddedCacheManager)cache.getCacheManager()).getGlobalConfiguration() Cheers, Sanne

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Some comments inline: 2010/8/23 Mircea Markus <mircea.markus(a)jboss.com&gt;: > On 21 Aug 2010, at 00:50, Sanne Grinovero wrote: > >> Hello, >> I was quite surprised to see that >> cache.getCacheManager() doesn't return the CacheManager but a >> CacheContainer, which I then need to cast to an EmbeddedCacheManager. > This was introduced with HotRod client. Both embedded and remote (hotrod) caches inherit from the same Cache interface. Also the structure that holds the caches is not a cache manager, but the CacheContainer - that's all that an remote and embedded cache container have in common. >> Shouldn't the signature of the interface be updated to return a CacheManager ? > I agree this method name is misleading and it breaking the API from 4.0. One thing we can do is: > - make getCacheManger return an EmbeddedCacheManager and deprecate it - to solve backward compatibility I don't think you need to deprecate it: current code was not released yet and previous release was returning a supertype of EmbeddedCacheManager. > - when called on an RemoteCache this would thrown an exception Maybe it would make sense for a next release to return the configuration of the remoted cache, possibly with additional information about the remoting configurations.This way the Hot Rod client would be more similar to the standard cache, maybe even configured with a similar XML approach (just thinking out loud). > - add a method Cache.getCacheContainer that would return an CacheContainer - this would be the suggested approach from now one I'd like to actually make use of getCacheManager, not getCacheContainer, as I need to read the configuration; so I wouldn't suggest the new method nor deprecate the getCacheManager. >> The methods exposed by a CacheContainer are rather useless, especially >> when returned from a cache instance as the only two I could use are >> getCache() and getCache(String cacheName); a use case to explain it >> better: >> >> ((EmbeddedCacheManager)cache.getCacheManager()).getGlobalConfiguration() >> >> Cheers, >> Sanne > I see what you mean. I do think that this CacheContainer abstraction has some benefits though: it allows one to write code that doesn't know weather it is using an embedded or a remote cache. Ok now that you pointed me to the RemoteCacheManager I understand the reasons. I'm fine with making no changes for now, but as it turns out that I've to cast often this defeats the purpose of being independent from the cache type. An alternative would be to use getConfiguration().getGlobalConfiguration(), but this latest one was deprecated and moved to the EmbeddedCacheManager, so maybe even getCacheManager() should be moved to the new implementation? Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 23 Aug 2010, at 14:18, Manik Surtani wrote: > How about getCacheManager() returning an EmbeddedCacheManager (if in-VM), +1. > and returning null if called on a RemoteCache, What about throwing an exception and telling the user to use RemoteCache.getRemoteCache instead?

> and RemoteCache defining a separate getRemoteCacheManager() method? That's already there ;) > > On 23 Aug 2010, at 11:28, Sanne Grinovero wrote: > >> Some comments inline: >> >> 2010/8/23 Mircea Markus <mircea.markus(a)jboss.com&gt;: >>> On 21 Aug 2010, at 00:50, Sanne Grinovero wrote: >>> >>>> Hello, >>>> I was quite surprised to see that >>>> cache.getCacheManager() doesn't return the CacheManager but a >>>> CacheContainer, which I then need to cast to an EmbeddedCacheManager. >>> This was introduced with HotRod client. Both embedded and remote (hotrod) caches inherit from the same Cache interface. Also the structure that holds the caches is not a cache manager, but the CacheContainer - that's all that an remote and embedded cache container have in common. >>>> Shouldn't the signature of the interface be updated to return a CacheManager ? >>> I agree this method name is misleading and it breaking the API from 4.0. One thing we can do is: >>> - make getCacheManger return an EmbeddedCacheManager and deprecate it - to solve backward compatibility >> >> I don't think you need to deprecate it: current code was not released >> yet and previous release was returning a supertype of >> EmbeddedCacheManager. >> >>> - when called on an RemoteCache this would thrown an exception >> Maybe it would make sense for a next release to return the >> configuration of the remoted cache, possibly with additional >> information about the remoting configurations.This way the Hot Rod >> client would be more similar to the standard cache, maybe even >> configured with a similar XML approach (just thinking out loud). >> >>> - add a method Cache.getCacheContainer that would return an CacheContainer - this would be the suggested approach from now one >> >> I'd like to actually make use of getCacheManager, not >> getCacheContainer, as I need to read the configuration; so I wouldn't >> suggest the new method nor deprecate the getCacheManager. >> >>>> The methods exposed by a CacheContainer are rather useless, especially >>>> when returned from a cache instance as the only two I could use are >>>> getCache() and getCache(String cacheName); a use case to explain it >>>> better: >>>> >>>> ((EmbeddedCacheManager)cache.getCacheManager()).getGlobalConfiguration() >>>> >>>> Cheers, >>>> Sanne >>> I see what you mean. I do think that this CacheContainer abstraction has some benefits though: it allows one to write code that doesn't know weather it is using an embedded or a remote cache. >> >> Ok now that you pointed me to the RemoteCacheManager I understand the reasons. >> I'm fine with making no changes for now, but as it turns out that I've >> to cast often this defeats the purpose of being independent from the >> cache type. >> An alternative would be to use >> getConfiguration().getGlobalConfiguration(), but this latest one was >> deprecated and moved to the EmbeddedCacheManager, so maybe even >> getCacheManager() should be moved to the new implementation? >> >> Sanne >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev