Now I bit more about the problem. The detached invokers , e.g. JRMPInvoker or JRMPInvokerHA work by unmarshalling an Invocation object off the wire, getting the ObjectName of the target service from the invocation, and then making a call on the MBeanServer similar to this: | Object returnValue = mbeanServer.invoke(targetObjectName, | "invoke", | new Object[]{invocation}, | new String[] {Invocation.class.getName()}); This approach requires that the service indicated by "targetObjectName" exposes a public void invoke(Invocation invocation) method in its mbean interface. You can see an impl of this method above. That's a pretty heavy requirement for a service, so for a non-HA service, the "targetObjectName" is actually the ObjectName for the ProxyFactory mbean that created the proxy. The proxy factory actually handles the invoke(Invocation) call and delegates to the real target service. The problem you are seeing is because ProxyFactoryHA doesn't work that way. It actually requires the end-user service to implement invoke(Invocation) itself. In addition, it forces the end-user service to do the | // Place our ObjectName hash into the Registry so invokers can resolve it | Registry.bind(new Integer(serviceName.hashCode()), serviceName); | call that you see in the example HAService.startService() method above. If that call isn't made you end up with the "java.lang.IllegalArgumentException: null object name" exception you reported in your bug report. So, the most obvious fix for JBAS-6284 is to get ProxyFactory HA to work the same as the non-HA factory. Not sure there aren't any lurking problems preventing that; we'll see. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195447#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...