I'm going to think out loud here, as this gets into an area where things aren't too clean. Apologies in advance for what I'm sure will ramble on.... I tend to think things through in writing. ClusterPartition is really playing two roles right now: 1) It's an impl of HAPartition that uses JGroups as an implementation detail. This is it's primary function. 2) There are services that use HAPartition for group RPCs and a JBC instance for maintaining shared state. These services need a guarantee that the HAPartition and the JBC instance are using a consistent underlying group comm layer (i.e. the group members for the HAPartition and for the cache are the same). ClusterPartition is acting as a guarantor. If you call getClusteredCache() and getHAPartition(), the two services are guaranteed to be using the same underlying JChannel. ClusterPartitionMBean should really just be a management interface for ClusterPartition -- i.e. something used by management tools like JBoss Operations Network or jmx-console. It shouldn't be used by clients like HA-JNDI. It also really shouldn't expose methods not needed by the mgmt tools. In this respect, ClusterPartitionMBean is pretty reasonable as a mgmt interface. The suspect methods are getClusteredCache(), getDistributedStateService() and getHAPartition() -- it's not clear what a mgmt tool would do with those methods. getMultiplexer() could be on the suspect list too, although I could see how a tool might want to navigate from ClusterPartitionMBean to the ChannelFactory. So, HA-JNDI shouldn't be using the mgmt tool interface to call getHAPartition() and getClusteredCache(). Which gets us to your question: what should it be using: 1) Don't want to add getClusteredCache() to HAPartition. We could (and should) have a separate discussion about what HAPartition is/should be. But in general its an abstraction of a group RPC layer, somewhat intended to hide JGroups. It then has two services bolted on via getters (DRM and DistributedState). Those really don't have anything to do with the RPC functionality other than since the interface clubs them together a client can assume the DRM/DS and RPCs are using the same underlying group comm channel. Hmm -- sounds familiar. Adding another getter to expose JBC further confuses things by pushing HAPartition away from its core function as a group RPC abstraction. It also goes against the idea that HAPartition hides JGroups. JBC is very much tied to JGroups. 2) Inject HAPartition, cast to ClusterPartition and make the getClusteredCache() call. Nah. 3) For DetachedHANamingService, injection type is ClusterPartition instead of HAPartition. Remove the attribute from DetachedHANamingServiceMBean -- tools don't need it; the microcontainer does, and a public method on the class itself is all the MC needs. The fact that ClusterPartition is injected into the service impl is an implementation detail. This solves the problem of HANamingService making calls against ClusterPartitionMBean. 4) Make a new interface that encapsulates the "guarantor of consistent HAPartition and JBC" function. (I have no good name for it.) Exposes getHAPartition() and getClusteredCache(). ClusterPartition can implement this interface. For DetachedHANamingService, injection type is this interface. This use of an interface leaves us free to refactor someday and break ClusterPartition's two roles into separate classes. I'm inclined toward #4. #3 seems OK for the immediate task but if we do it we should add a subtask to JBAS-4276 to look at it again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4063467#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...