HAJNDI and JNDIView

[adrian.brock]

Feature Request:

Shouldn't JNDIView have some processing to detect (MBean query?) HAJNDI instances
and list the bindings that are replicated?

[ben.wang]

That's a good suggestion. Maybe Jerry can say more about this (because he is the HA-JNDI guy now ;-) But it should just involve using ha-jndi initial context from JNDIView, isn't it?

So we will have a regular JNDIView for local jndi and maybe an additional API for HA-JNDI listing?

[jerrygauth]

Sorry for the late response. I inadvertently haven't tracked this forum for a month or so and I just noticed the postings.

I can create a JIRA issue to track this feature request, which should be fairly simple to implement. There are at least three ways that we can accomplish this.

1) Add new methods to JNDIView such as listHA() and listXMLHA(). These would return the HA-JNDI store in a cluster environment and null otherwise.

2) Modify the existing HAJNDI mbean to provide list() and listXML() methods similar to the ones in JNDIView().

3) Add a HAJNDIView mbean that's the HA version of JNDIView.

Any recommendations?

[adrian.brock]

You shouldn't need to modify HAJNDI, it already supports list().

All you need to do is make JNDIView aware that the context exists.
Or have a mechanism for JNDIView to discover the HAJNDI contexts.

[adrian.brock]

NOTE: I don't intend that you should support listing "discoveries"
only the bindings that are replicated, i.e. the list() will be a local operation.

[jerrygauth]

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.

[jerrygauth]

I've created JBAS-2516 and JBCLUSTER-74 to track this issue.

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.

[starksm64]

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.

[jerrygauth]

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.