It's really just a matter of whether we want to support a bit of convenience code. My inclination is to think we shouldn't as it's just cruft. But I don't feel that strongly about it. I don't know that much about what kind of facilities other environments offer. a) Can they parse a deployment descriptor (a la -service.xml, but their format), use it instantiate a pojo (aka CacheLegacyJmxWrapper) and inject config elements into it and then register that pojo in JMX? If no, then the user is going to have to deal with JMX themselves anyway (programatically). In that case, providing a convenience method doesn't buy much. User still has to provide us a ref to the MBeanServer and the ObjectName of the JChannelFactory. They just avoid the trivial lookup call. If yes to a), then b) Does the facility in a) have the ability to inject complex mbeans a la the AS's "depends optional-attribute-name" feature? If yes, then it's the same case as JBoss AS -- they should just inject the JChannelFactory. If no, then we have a use case for JMX lookup. If we do decide to support this, the ObjectName should be removed from Configuration, and be added as an attribute of CacheLegacyJmxWrapper (or maybe CacheJmxWrapper). That object then does the lookup during it's create call, and injects the JChannelFactory into the Configuration. This will only work if user registers the CacheJmxWrapper in JMX before calling create(). Otherwise, no MBeanServer will be available to CacheJmxWrapper to do the lookup. I definitely think we shouldn't support attempting to find a JMX server the way we do in 1.4. That just leads to trouble. If people want JMX, they register the wrapper; wrapper gets a preRegister callback during registration, and from that the wrapper has a ref to the MBeanServer to use to register cache internals like the interceptors. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039849#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...