Menu
▾
▴
#219 MBean Info Persistence
Now that we have MBean persistence, it makes sense
to have MBean Info persistence. Specifically, this
allows for MBeans to be generated at runtime, yet
remain in the server after restart.
I've made several changes to the JMX module, including
the build scripts, resulting in the following application
flow.
1. An MBean is created dynamically, with descriptors
that designate that its MBean Info should persist.
2. The MBean is registered with the server using the
standard technique.
3. Before registration, the (RequiredModel)MBean
inserts its resource class name into its descriptor.
4. Immediatly after registration the Registry checks the
MBean's descriptor -- if it is flagged for MBean Info
persistence, then the server adds it to the MBean Info
DB (a separate MBean).
5. Based on its persistence policy, the MBean Info DB
flushes its MBean Info objects to the disk, at the
appropriate time.
6. When the server starts, the MBean Info DB is
loaded, at which point its PersistenceManager.load() is
called, and the mbean infos are read from the disk into
memory.
7. The class name mentioned in step #3 is then read
from the MBeanInfo and used to create the resource
object.
8. The restored MBeans are then registered with the
server.
Further work to be done (in no particular order):
1. Allow resource classes with constructors other than
the default to be loaded.
2. Persist to XML instead of Object Streams.
3. use notification in the basic mbean registry to flush
the mbean info persistence queue (see the comments in
the source code for details)
4. Verify the build script modifications. I made small
changes to the build scripts for deploying the
descriptors for the MBeanInfo DB service. I'm not sure if
the modifications I made are optimal. Maybe xdoclet
generation of the descriptors would be better...
5. Change the JMX domain for the MBean Info DB from
user:service to something more appropriate (I wasn't
exactly sure what this should be)
6. ?
For those who might be wondering why I used a
delegate for the MBean Info DB, rather than making the
registry itsef a persistent MBean -- the reason is that
the registry MBean is loaded into the server prior to
services required for successful operation of the
persistence interceptor. Rather than try to hack the
persistence interceptor, pushing the mbean info
persistence function into its own MBean (which isn't
loaded until those essential resources are available)
seemed appropriate. This also allows a decoupling that
might be appealing for some.
I look forward to comments / feedback / etc.
- Matt