Change Notes item #625337, was opened at 2002-10-18 12:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=625337&group_id=22866
Category: JBossMX Group: v4.0 Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: MBean Info Persistence Initial Comment: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=625337&group_id=22866 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
