ObjectName conventions for multi-classloader, clustered environments

Question

I've been reading a number JMX documents, including these best practice articles [1] [2], but I've run into a question about the practical application of the ObjectName conventions within a multi-classloader and/or clustered environment.
The general suggestion is to use a singleton name that's unique within an MBeanServer (environment). For example, my.counter:name=CounterPool. This is fine when running one instance of an object within a JVM, but what about mult-classloader environments where an object could be loaded multiple times and causing multiple registrations, which would obviously fail. The best example of this would be code running in a Web container that gets deployed to two separate applications (WARs).
What's the best practice for naming an MBean that uses the platform MBeanServer, but could be loaded multiple times by multiple class loaders?
[1] http://java.sun.com/products/JavaManagement/best-practices.html
[2] http://www-128.ibm.com/developerworks/java/library/j-jtp09196/index.html

Answer 1

That's certainly an interesting question!
If an MBean can be created by two different apps running in the same JVM, then the question is whether it reflects something about each app individually or some global state. For example, if the my.counter:name=CounterPool MBean sometimes represents the counter pool of the Fred app and sometimes of the Jim app, then its name should reflect that. You might imagine adding an extra key to the ObjectName, like my.counter:name=CounterPool,app=Fred. (You should also have a type key, by the way.) Or, you could imagine that each app has its own domain, like Fred/my.counter:name=CounterPool.
This can be tricky if the MBeans are being created by a library. I think a library that could be used independently by different apps in the same JVM should not create an MBean with a hardcoded ObjectName unless the behaviour of that MBean is the same no matter what app registers it. If the MBean reflects the state of the library, then that state will be different for the copy of the library in each app, so registering a single MBean is wrong.
If the MBean reflects global state (like the hostname or the filesystem or whatever, which will be the same for each app), then it does seem reasonable to use a fixed name. In that case, the library could try to do the following. Suppose the name of the MBean is d:k=v.
* Register an MBeanServerNotification listener on the MBeanServerDelegate using an MBeanServerNotificationFilter, to be informed when the d:k=v MBean is unregistered.
* Try to register d:k=v. If this fails with InstanceAlreadyExistsException, then somebody else got there first.
* When you get an MBeanServerNotification saying that d:k=v has been unregistered (the other app went away), you register your own d:k=v. Again, if you get InstanceAlreadyExistsException you can ignore it.