The issue really isn't why the local-jndi-name is variable, its why the local-jndi-name is being used in the jmx name. The jmx name should be independent of this using the deployment structure and ejb-name as this has to be unique.
Absolutely agree with that. I'm just saying that the fix for the jndi problem has caused other problems in the jmx area. Object names need to be unique obviously and I was proposing a way to make them unique, but stable. As far as I'm concerned the jndi fix caused a regression in proper jmx support.
Looking into the jsr-77 spec further... it states "The value of the name key property for managed object instances of the J2EEDomain type must be equivalent to the domain name of the domain it
manages."(JSR-77 FR, 22-23)
JBoss uses the domain jboss.management.local even when the J2EEDomain object declares the domain to be Manager.
I'd still like to see the service EJB fixed as well though.
So lets fix the object names. The JSR77 names are independent of the ejb container names and can be fixed without any changes to the ejb container use of jmx names.
We also need testscases asserting the consistency and structure of the names used. All projects need to be cooperating in terms of asserting which apis are being used by providing or at least creating jira issues for their usage requirements.
Regarding jsr77 names, although it is now clearer how to identify the jsr77 root domains, I think we could consider leaving inside the 'jboss.management.local' domain only the jsr77 generated mbeans, and take outside the 2 "manager" services. So
I don't think there are other services referencing the 2 manager mbeans?