Re: [infinispan-dev] about cache.getCacheManager()

How about getCacheManager() returning an EmbeddedCacheManager (if in-VM),

and returning null if called on a RemoteCache,

and RemoteCache defining a separate getRemoteCacheManager() method?

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