[ https://issues.jboss.org/browse/AS7-6367?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-6367: ----------------------------------- A bit of background to this issue. Currently the EJB3 subsystem allows pointing to just one remoting connector (configured in the remoting subsystem): {code} <subsystem name="ejb3"...> <remote connector-ref="foo" thread-pool="default/> ... {code} The "foo" connector is in turn configured in the remoting subsystem. The foo connector is backed by a security-realm. Effectively, this means that all remote EJB communication that happens will happen via the foo connector and as a result will use *only* that single security-realm. The goal of this JIRA task was to allow the EJB3 subsystem to point to more than 1 remoting connectors configured in the remoting susbystem so that remote applications can then choose from these available remoting EJB connectors for EJB communication. This looked straightforward to implement when I initially started work on this. All I had to do was allow something like: {code} <subsystem name="ejb3"...> <connectors> <remote name="one" connector-ref="foo" thread-pool="default/> <remote name="two" connector-ref="another-one" thread-pool="default"/> ... </connectors> ... {code} instead of the previous configuration. But when I started implementing this I realized that it isn't straightforward keeping in mind the backward compatibility goals. It took a (long) while to get the transformers right for these configurations. As of today, I've the transformers functional and the above changes are working. However, while doing some manual testing around this, I've realized that our previous model/xml had a incorrect notion of configuring channel-creation-options for the remote EJB connector. It allowed something like: {code} <subsystem name="ejb3"...> <remote connector-ref="foo" thread-pool="default> <channel-creation-options> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> </channel-creation-options> </remote> ... {code} Those channel-creation-options were then used while registering a EJB channel handling service against the remoting Endpoint. Now with the changes were are proposing, this will no longer work out - i.e. each remote connector configuration in the EJB subsystem *cannot* be allowed to specify different channel-creation-options. In fact, it doesn't belong to the individual connector and instead it should be at the EJB subsystem level since that service should be registered just once. So this is going to require a lot more (re) work to implement this feature. I'm currently working on this one and have a different schema/model in mind. Something like: {code} <subsystem name="ejb3"...> <!-- Remote element represents the "remote" aspects of a EJB subsystem and doesn't necessarily mean a remoting connector. In fact, that was the original goal when this element was introduced, but got messed up somewhere down the line --> <remote> <!-- The remote aspect of a EJB susbystem can have connectors --> <connectors> <!-- A connector which is backed by remoting subsystem --> <remoting-connector connector-ref="foo" thread-pool="default"/> <!-- Possibly n future a HTTP connector <http-connector ..../> --> </connectors> <!-- Notice that now we have these channel-creation-options outside of the individual connectors so that they are applicable to the entire EJB subsystem --> <channel-creation-options> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> </channel-creation-options> ... </remote> .... {code} This is going to take some work to get it functional. I'm working on this one in parallel with some other tasks. I'll update this JIRA once this gets done. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira