[infinispan-dev] about cache.getCacheManager()

[Sanne Grinovero]

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