<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I've checked in ongoing work of the hotrod client; it would be great to get some feedback on the public API, especially RemoteCache[1] and RemoteCacheManager[2].<div>For now RemoteCacheManager does not implement CacheManager interface, see email bellow.<br><div><br></div><div>[1]&nbsp;<span class="Apple-style-span" style="font-weight: bold; "><a href="http://tinyurl.com/yhb793b">http://tinyurl.com/yhb793b</a></span></div><div>[2]&nbsp;<b><a href="http://tinyurl.com/yh6j2we">http://tinyurl.com/yh6j2we</a></b></div><div><b><br></b></div><div><b>Cheers,</b></div><div><b>Mircea<br></b><div><br></div><div><br><div><div>On 23 Mar 2010, at 23:16, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div 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&nbsp;that would implement&nbsp;CacheManager&nbsp;(similar to the way in which DefaultCacheManager implements&nbsp;CacheManager; it&nbsp;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:&nbsp;<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. &nbsp;Approach 2 - do not extend it. This would result in a clearer API</div><div>3.&nbsp;Approach 2 -&nbsp;Extract the &nbsp;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></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br></div></div></div></body></html>