anonymous wrote : The AS's channel factory bean is already an AS-specific impl of the ChannelFactory interface. I intend to alter the impl of the "createMultiplexerChannel" methods so they analyze the configuration of the specified protocol stack. If it supports a shared transport, I will return a shared transport channel. If not, I will return a MuxChannel+Multiplexer+JChannel. This is a bit hacky, given the name of the method, but I think the benefits are worth it. This has evolved further. The AS ChannelFactory will never return a MuxChannel. If a user invokes one of the createMultiplexerChannel methods and the TP config doesn't include a singleton_name, I'm going to create a singleton name for that channel and inject it into its config, log a WARN and return a shared transport channel. Created name will be "unamed_" + stack_name. http://jira.jboss.com/jira/browse/JBAS-5442 Re: the hackiness of the AS approach given the name of the method, I suppose it's a bit less hacky than I was thinking. A shared transport channel is still a "multiplexer channel". The multiplexing happens in the transport itself, when it chooses what up-protocol to pass an incoming message to. The fact that JG had another impl that involved an implementation detail class called "Multiplexer" doesn't mean the word multiplexer is forever reserved for that particular impl. The AS fix is still hacky though, as the method signatures of the two createMultiplexerChannel methods include other params besides the stack name that are now totally ignored. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4144208#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...