MBean ObjectNames are a garbled mess!

[amlodzin]

Another JBoss failure!

The ObjectNames used to identify many of the MBeans within JBoss are poorly constructed. Some MBeans are for the most part inaccessible programmatically.

Sure, you can see them all via the web-console, but try automating a monitoring task! No easy feat. For example, it's nearly impossible to determine the state of each deployed application and EJB jar and standalone WAR. You can come close if you dare to make some assumptions, but it shouldn't have to be this way. Every other appserver I've worked with make it not only possible, but downright easy (OracleAS, WebLogic, WebSphere).
The problem, in the app-state case, is that the "jboss.web.deployment:*" MBeans use a random id as a key property, in addition to just one other key property - the war file name. That makes it impossible to link a particular war file with its parent EAR file (if there is one) when several ear files are deployed containing the a war file with the same name.

EJB and EJB3 modules use completely different domains and key properties, thus require unique code to link them to their parent apps.

And why do all MBeans in the "jboss.web" domain use a value of 'none' for the 'J2EEApplication' key?

JBoss' JMX support is yet another reason why JBoss remains an insignificant player in the world of industrial-strength J2EE app servers.

[dimitris]

"amlodzin" wrote:

The problem, in the app-state case, is that the "jboss.web.deployment:*" MBeans use a random id as a key property, in addition to just one other key property - the war file name. That makes it impossible to link a particular war file with its parent EAR file (if there is one) when several ear files are deployed containing the a war file with the same name.

Where do you see that - which AS version?

Also, I'd be interested in some hard facts about JBoss' insignificance, rather than some random ranting.

[amlodzin]

"amlodzin" wrote:

The problem, in the app-state case, is that the "jboss.web.deployment:*" MBeans use a random id as a key property, in addition to just one other key property - the war file name. That makes it impossible to link a particular war file with its parent EAR file (if there is one) when several ear files are deployed containing the a war file with the same name.

Where do you see that - which AS version?

Every version of JBoss 4.x, including at least 4.0.2 to 4.2.3.
Also, JBoss 5.0.0 does away with the random id - but replaces it with NOTHING! So, if you could find the ID in 4.x (say, hidden in the Exception generated by jboss.system:service=MainDeployer.checkIncompleteDeployments()), you might have had a chance of matching it up to the MBean that contains the modules StateString. In 5.0.0, that chance, however slim, is gone completely.

Also, I'd be interested in some hard facts about JBoss' insignificance, rather than some random ranting.

Got your attention, didn't it ;)
In our business of providing monitoring solutions for J2EE middleware, we always build support in stages: WebLogic 1st; WebSphere 2nd; OracleAS 3rd; JBoss last. I'm sure there are reasons beyond what the various appservers have to offer - but we follow the money.

[amlodzin]

Wow - JBoss 5.0.1 doesn't even have a 'state' associated with any WebModule. The jboss.web.deployment MBeans still have the start() and stop() operations, but the StateString attribute is gone.
Finding out whether a particular application has all of it's modules in a running state or not just got even more difficult!
Thanks JBoss :(