<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div>While presenting the hot rod client java API in Brno, we agreed to use a RemoteCacheManager that would implement CacheManager (similar to the way in which DefaultCacheManager implements CacheManager; it is used for clients from the same namespace).</div><div>Looking at the CacheManager interface[1], most of the methods that do not make sense on the RemoteCacheManager: <span class="Apple-style-span" style="font-family: monospace; white-space: pre; ">defineConfiguration, getClusterName, getAddress, isCoordinator, getStatus, getGlobalConfiguration, getDefaultConfiguration and getCacheNames. </span></div><div>The only two methods that really make sense are: getCache() and getCache(cacheName:String). So here are some thoughts I have about having RemoteCacheManager implementing CacheManager.</div><div>1. Approach 1 - throw exceptions for the unsupported methods. Not a very nice approach IMO, given the fact that most of the methods fall in this category, which would make the API a bit unusable</div><div>2. Approach 2 - do not extend it. This would result in a clearer API</div><div>3. Approach 2 - Extract the two getCache methods in an super interface (CacheHolder, CacheRepository, ??) and have both CacheManager and RemoteCacheManager implement it - this one I like the most as it encourages reusability and keeps the API clean.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Cheers,</div><div>Mircea</div><div><br></div><div>[1] <a href="http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/manager/CacheManager.java">http://anonsvn.jboss.org/repos/infinispan/trunk/core/src/main/java/org/infinispan/manager/CacheManager.java</a></div></body></html>