I don't have time to think this through extensively, but I would like the MBeanRegistry to persit the mbean info of either
--all mbeans or --all mbeans with a particular descriptor in their mbeaninfos. I want to change the use of the ServiceController/Creator/Configurator so it is ONLY used when you first deploy a package, NOT when you shut down jboss and restart it. I want the mbean persistence mechanism to take care of reestablishing all the mbeans previously present. I think that following Juha's suggestion and persisting the entire mbean registry is the best way to do this. If you get this working I will take care of making the ServiceController stuff not interfere. For making it work in the short term perhaps only persisting mbeans with a particular descriptor will be the best plan, you can set this descriptor for your dynamically created mbeans now, and we can set it for all the others later. thanks david jencks On 2002.10.02 10:23:50 -0400 Matt Munz wrote: > A slight correction -- when I refer to *-service.xml, I really mean > *-service.xml _and_ the XMBean definition XML. > > - Matt > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Matt > Munz > Sent: Wednesday, October 02, 2002 10:06 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] creating persistent MBeans dynamically > > > Hi all, > > Now for the interesting stuff... At this point, I have dynamic creation > of > MBeans figured out -- I can even get them to persist and reload their > state > through a manually-assisted process. The next step is to complete the > cycle > by loading the metadata of the MBeans at runtime. > > There are some options here. Juha wrote the following. > > >make the mbean registry persistent (it's already an mbean) triggering > >store() on registerMBean() calls, and have your widget factory register > >mbeans using the registry mbean operation registerMBean(Object, > >ObjectName, Map) where you pass in the valueMap the additional info to > >store for recreating the mbeans (constructor signature, args, other > config > >info). At registry load() read and recreate mbeans, and then mbeans each > >load() their state. > > The MBean registry is a large Object graph, comprising much of the > entire > server. It seems that this is a lot to tackle, as I don't want to > serialize/deserialize the entire server, just a few dynamically created > MBeans. > > I'm willing to try this, or any approach that makes the most sense, but > I'd like to hear more design ideas on the subject before going forward. > > Here's the direction I'm coming from... > > The process for creating MBs is 1) make MBeanInfo, 2) Make an MBean > with > that MBeanInfo, and 3) register. After #3, the state of that MBean will > be > persisted, if appropriate. What will not be persisted is the MBeanInfo > generated in step #1. In the case of MBeans created by the > ServiceCreator/Deployer, the MBeanInfo is already persistent (stored in > *-service.xml in the deploy folder). To achieve this, the dynamically > created MBeans need a mechanism to A) persist the MBeanInfo, and B) > reload > the MBeanInfo and execute steps #2 and #3 at server start. After that, > the > system will work automatically. > > This is where I could use some design input. (A) is relatively > trivial. > To achieve (B), I could create an MBean responsible for loading MBeans > from > the MBeanInfo database created by (A), at startup. This, of course, is > precisely what the Service Deployer does, with the difference that this > deployer will not try to load the MBeanInfo stores when they are written > (A). > > Perhaps the solution is to provide a programmatic interface to the > service > deployer that will write the MBeanInfo for a given MB to the deploy > folder, > but won't try to re-deploy it? Pheraps there is a better idea? > > - Matt > > > > > > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 > > ------------------------------------------------------- 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
