I wanted to note one thing that I forgot in my initial explanation. The reason that lead me to look at all this was the fact that I need any SingletonStoreCacheLoader implementations to extend AbstractDelegatingCacheLoader. I would rather customer having to implement an interface rather than extend a class as it gives them more flexibility. They can always extend AbstractDelegatingCacheLoader and gain from the benefits of overriding just the methods they want, but if alternatively they can implement an interface with getCL/setCL (a name that implies a CL that delegates to another CL, with the possibility of getting/setting the underlying CL), much better :) I totally agree with the naming being confusing, hence my attempt to make a separation between cache/CL delegating CLs. I think TcpDelegatingCacheLoader is a bit different to the rest of cache delegating caches. The rest, LDCL, CCL, and the possible outcome of http://jira.jboss.com/jira/browse/JBCACHE-789, do pretty much the same, delegate cache loading to other caches. First one to a local cache, second to another cache via MethodCalls (using the caches RPC manager) and the third one via proxies. All three just mentioned could just extend AbstractCacheLoader as you said and override what needs overriding. I like this idea (which is what u're saying in your 1st paragraph) more than having CCL extend DCL. anonymous wrote : AbstractDelegatingCacheLoader (which delegates to other cache loaders) - makes more sense in it's implementation Of course it does!!, i created it myself! hehehehe :-p ;-). This is the cache loader that I want getCL/setCL factored out into an interface to make people who re implement SSCL easier as mentioned earlier. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064781#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...