[jboss-jira] [JBoss JIRA] Closed: (JBCACHE-1044) RuntimeConfig's channel factory should be type ChannelFactory not JChannelFactoryMBean

RuntimeConfig's channel factory should be type ChannelFactory not JChannelFactoryMBean -------------------------------------------------------------------------------------- Key: JBCACHE-1044 URL: http://jira.jboss.com/jira/browse/JBCACHE-1044 Project: JBoss Cache Issue Type: Sub-task Security Level: Public(Everyone can see) Components: Clustering Affects Versions: 2.0.0.CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0.CR2 The org.jgroups.jmx.JChannelFactoryMBean interface is a management interface that wraps an instance of org.jgroups.ChannelFactory. JBC 2.0.0 should be pojo-based and not rely on a JMX server for integration. So, RuntimeConfig.muxChannelFactory should be of type org.jgroups.ChannelFactory. Implications: 1) If the Configuration is built programatically, the program should inject the ChannelFactory or the Channel. XmlConfigurationParser can't do that and will log a WARN if asked to handle the legacy MultiplexerService attribute. 2) If the Configuration is built via an IOC framework, the framework can build the ChannelFactory pojo, and inject it into both the JChannelFactoryMBean and the RuntimeConfig. 3) If the Configuration is built from a -service.xml via a JBoss AS 4.x ServiceController, CacheLegacyJmxWrapper will add a "MultiplexerService" attribute into which the ObjectName of the factory can be injected. This is solely to support the legacy "MultiplexerService" attribute from JBC 1.4.1.x. CacheLegacyJmxWrapper.create() will then invoke an mbean operation on the factory to create the multiplexer channel, and will pass the *Channel* into the RuntimeConfig. Thus CacheLegacyJmxWrapper and superclass CacheJmxWrapper remain as the only classes that deal with JMX operations. #3 above is an obscure use case, since AS 4.x will not work with JBC 2.x if the distributed web session or clustered EJB3 services are running. It would only apply to people who remove those services and want to run their own cache-based service using JBC 2.x. Given that, I'm tempted to drop #3 and just no longer support the legacy "MultiplexerService" attribute.