Specifications of deployment and lifecycle of JMX beans in a JEE server

Question

Hello,
one colleague of mine is developping a service that uses an MBean to mimick a singleton (the MBean is not used for instrumentation or administration, it just holds a pool of shared non-standard resources) within a Glassfish server.
I fought this idea (as I found a static utility would be both straightforward and easy to implement), but I took it, from this forum in particular, that it is a recommended way to use an MBean to serve as a shared resource holder. Point taken (I'm not concerned with clustering yet, I mean it's OK if the singleton is not cluster-wide)
The problem is, my colleague warns that he witnesses "strange deployment behavior" with regard to the MBEan: in particular, it seems that the MBean is not unregistered upon EAR undeployment, and not redeployed upon EAR re-deployment. In particular updates to the MBean code (currently packaged within the EAR) require a server restart to take effect.
From what I understand, the MBean is registered in a JVM-wide registry (the MBean server), and its classs and instances have a different lifecycle from the EAR, which has (some sort of, obviously more complex in the details) class-loader scope.
I admit I'm making that up, from various observation -> my main problem is that I can't find an appserver-agnostic specification of the MBean lifecycle in a JEE environement. The EJB3 specification do not mention JMX (but as I understand it EJB3 alters none of the way JMX works).
There seems however to be a J2EE-specific way of handling MBean - presumably because the hot-deployment-without-JVM-restart expands the MBean lifecycle beyond the EAR lifecycle.
Could you point me to authoritative references on JMX used in JEE servers. In particular specification of the lifecycle and deployment is extremely welcome.
I'm sorry for asking pointers: my own web searches turn up non-specifying docs.
And if I search on JMX and Glassfish together, I find articles on either:
- how Glassfish uses JMX to implement a lot of stuff, but not how Glassfish implements "JMX lifecycle" (if that expression even means something).
- how to extend Glassfish's adminsitration capabilites writing custom MBeans
Thanks in advance,
J.

Answer 1

The location of the registration code is thus the key to all this. e.g If you register manually in some startup class, you can unload/load the required versions of the MBean code.That's what we do (using a RegistryServlet and init()/destroy() callbacks).
Sketchy description from what I understand of the developer's code: the init() indeed looks up the MBean and unregisters it if it exists, then registers it anew. Sometimes, the unregistering will fail (I haven't witnessed that), which triggered this topic.
We have to investigate it further (with more rigorous archiving and analysis of the error logs). I'll post updates if any.
If the MBeans are configured to be registered by the server itself (common) then the server would need to be restarted for the changes to be picked.OK. I have no idea how to configure where the MBeans are registered, time now to confess I have used JMX only in trivial cases so far.
It is my sincere hope that you won't need to use the techniques of chapter 8 of [this specification|http://java.sun.com/javase/6/docs/technotes/guides/jmx/JMX_1_4_specification.pdf] .
Indeed!
Probably my lack of JMX knowledge, but I have no idea what the "Mlet service" is in my scenario, and I suspect I won't want to know :o)
Overall this suggests that using JMX introduces unforeseen complexities, that may be overkill in our scenario (but I'm biased as I defended a couple of other alternatives).
Thanks for your help so far; I'm still looking for some document that would clarify how the JEE server, or how Glassfish specifically, handles MBean lifecycle.