Just a bit of philosophical overview to make more explicit what I'm thinking about JMX and 2.0: 1) JMX becomes something used for exposing mgmt info to mgmt tools a la jmx-console, JON, jconsole, whatever. Internally JBC doesn't use it. No JMX lookups, etc. 2) We provide wrapper classes that implement mbean interfaces. User is responsible for getting those registered in JMX. In the AS they can use the tools the AS provides to help them do that (e.g. MC parsing of -service.xml or -beans.xml), but getting it done is up to them. The effect of this is JBC never has to worry about: a) figuring out what the MBeanServer is. b) figuring out what ObjectName to use. 3) For external objects like a JGroups ChannelFactory, JBC has no interest in JMX. If user wants their channel factory registered in JMX, they should do that themselves. JBC is interested in the raw channel factory. 4) The one JMX-related thing JBC should do is allow its JMX wrapper classes to register mbeans for the interceptors. JBC takes responsibility for this only because the interceptors are internal details of the cache; making users get hold of them and register them is too much to ask. CacheJmxWrapper is able to perform this service because when it is registered it gets a callback informing it of the mbean server and its own ObjectName. From that it's easy to create unique names for the interceptors based off its own name and to then register them using the provided mbean server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4041900#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...