If there is going to be a check for an entry in the collocation map, then effectively the GUID becomes irrelevant. Other cleanup than could be done is removal of the unused remoteInvoker instance variable.
Only if the non HA invoker deployment also maintained the colocation info.
Ok, I thought you were indicating that the base InvokerInterceptor was going to be checking for existence in the collocation map which would require the non-ha proxy factories to maintain this info. Its a less intrusive change if the GUID continues to be a marker for non-ha collocation and only ha proxy factories maintain the explicit collocation mapping. This would require one new HAInvokerInterceptor as far as I can see.
Actually implementing this, there is no need for a Colocation object.
This object already exists in the form of org.jboss.system.Registry
(it should needs adding to the client jar where it will be empty on a client).
Also, looking at org.jboss.proxy.ejb.ProxyFactory
This looks wrong. It creates and binds the proxy in start(), but doesn't remove it
until destroy(). I can see circumstances where it or a subclass/dependency
needs some service that is no longer there.
Anything in done start() should be reversed in stop()!
So are you ready to pull the commit action on this?