I would suggest if we can we make that a follow up task,if there is any change to the message format we will need a new message version anyway, switching to Elytron authentication is the first important step. But good to know we have an InvocationTracker available now - that felt like a problem every client library was having to solve.

Depending on what happens, it may be advisable to switch to using org.jboss.remoting3.util.InvocationTracker for request/response correlation. It removes a bit of boilerplate and also prevents problems like hitting message limits and common race conditions and leaks.

Yeah we'll have to circle around to the controller-client to ensure that it starts to use the same connection sharing. I'll make a JIRA for that as well.

Since connections would no longer be locally managed, acquiring a Channel has to be changed to match the idiom found in jboss-ejb-client - basically, existing channels are joined and new channels must be opened, but in a concurrency-safe manner.

Hopefully that will solve another problem we had integrating Remoting JMX with the CLI - where we have to manually make the connection available if we want to share it.

Also once we get back within the application server it could hopefully make proxying the MBeanServer from a different process much much easier.

This will have to be done in lock-step with REMJMX-109. Also, this entails switching to Remoting client connection management - in other words, switching to Endpoint.getConnection() instead of Endpoint.connect(), and relying on Endpoint.getCurrent() instead of constructing custom endpoints for client or server. Locally configured authentication items should be considered "legacy" and could be used to construct a composite AuthenticationContext based on the captured one, if they are present, to allow them to continue to work.