Fix for JBAS-2651 (Restore stable JSR77 names for ejbs)

[starksm64]

So the first question I have is, is fixing the jsr77 name what is needed? This is actually independent of the ejb container jmx name and there is no dependency on it. The same is not true of the ejb container jmx name as its pattern has been documented for use with depends statements.

[ghinkle]

Agreed, can't break users' dependency statements. We could only use the deployment context names in cases where we would have used the hashcode anyway.

We've been using the ejb container mbean, but it looks like we can gather most of what we need from the jsr-77 mbean instead. It'll be a backward compatibility issue for the ON product, but we can work around that.

So, what'll it take to fix the jsr-77 name. It looks like the domain is currently not in agreement with the name of the J2EEDomain object which seems to be out of spec. So, do we want to change the name of the domain ojbect or the domain of all the objects.

Second, the name attribute will have to be made static. No reason not to just use the old style name (sans the hashcode).

[starksm64]

I don't think we should be using the jndi name at all in the jsr77 name. An ejb having only local interfaces or an mdb has no reason for a jndi name. Its a jboss implementation detail that could change in the future so we need a non-implementation detail based name. For the jsr77 names, we can simply use the ejb-name because the jsr77 structure requires that this be unique due to the fact that it is scoped by the EJBModule (EJBModule, J2EEApplication, J2EEServer). The same is not true of the ejb container jmx name pattern, which is why we used the jndi name.

I'm not following the problem with the J2EEDomain. Can you give an example of what you mean.

[starksm64]

So the jsr77 name is already independent of the jndi name as the ejb part is simply the bean ejb-name. How the managment layer discovers/queries ejbs is what needs to be described.