Sorry - I meant the mbean named "service=HAJNDI" could provide list() and listXML() methods. This mbean implementation is actually DetachedHANamingService, not HAJNDI (which does already have a list method).

It should be possible to make JNDIView aware of the potential existence of HAJNDI by having it try to create an initial context using an HAJNDI port. If the context is created, it can then use normal JNDI methods to extract the bindings from it.

The JNDIView output would probably need to have three separate namespace sections; the existing ones for "java: Namespace" and "Global JNDI Namespace" as well as a new one for "HA JNDI Namespace." This would be necessary to disntinguish between Global and HA bindings; it's also possible that there could be an overlap as a name can be bound locally as well as via HAJNDI.

So if we proceed in this manner, the HAJNDI namespace will be displayed via the existing JNDIView mbean., which seems reasonable.

I prototyped this by modifying JNDIView to include the HA-JNDI bindings. I created the necessary initial context with a hardcoded HA-JNDI port for expediency. Everything worked as expected and the listing provided the HA-JNDI bindings as well as the local bindings.

The design issue here is how to properly obtain the HA-JNDI initial context. Everything else should trivial.

This should be queried at runtime from the HANamingService. The JNDIView should have an attribute for the HANamingService ObjectName that is used to query for the service, and should it exist, obtain the port of the HAJNDI bootstrap proxy.

Right. Getting the binding address and port from the HANamingService (if available) works fine and is sufficient to obtain the HA-JNDI initial context. Changes should be checked into 5.0 within a day or so.

This is probably trivially backported to 4.0.x so I'll look at that after modifying 5.0.