After filing bug [ERRAI-422|https://issues.jboss.org/browse/ERRAI-422], I tried simply calling bus.init() to reconnect the disconnected bus, ignoring the BusControl instance passed to the TransportErrorHandler, and it seemed to do the trick. (Background: ERRAI-422 is about brokenness in the BusControl.reconnect() method which is supposed to be used to reconnect a client-bus after it suffers from an HTTP transport error.)
Given the apparent success of my little experiment, I'm now wondering:
1. Does this actually work, or will it leave the reconnected bus in some subtle defective state?
2. Is the complexity of the BusControl interface really necessary? Can't the API simply be "to reconnect a bus (or force re-federation), call ClientMessageBus.init(), and to disconnect a bus, call ClientMessageBus.stop()"?
It seems like a bus should always know if it being "reinit'ed" (versus initialized for the first time), so it is not like a BusControl instance has any novel state associated with it. Perhaps a TransportError instance should be able to provide the bus to which it applies (i.e. a getBus() accessor instead of getBusControl()) --- but even that doesn't seem strictly necessary since it is trivial for a user to make sure a TransportErrorHandler remembers the bus to which it is attached.
