[infinispan-dev] about cache.getCacheManager()

[Manik Surtani]

On 23 Aug 2010, at 17:52, Mircea Markus wrote:

> 
> 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?

Works for me.

>> 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 at jboss.com>:
>>>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org