David, Thanks. That helps a lot.
Regarding persisting MB info... > 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. What about re-deployment? If, after server start, I modify/touch a package already in the deploy folder, will it be re-deployed? > For making it work in the short term perhaps only persisting mbeans with a > particular descriptor will be the best plan, Makes sense to me. > I think that > following Juha's suggestion and persisting the entire mbean registry is the > best way to do this. Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server. To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). Isn't this excessive? I would prefer to persist only the MB info objects for these beans, as the rest of the state is unnecessary. As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? Regarding the JMX spec... I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). One issue that isn't discussed is the set of expectations for registration that relate to the server lifecycle. When I register my MB, is that for the current "session" (whatever that may be), the life of the server, the life of the JVM, perpetuity, etc. ? If registration is intended to last for the life of the server only, then MBs would expect not to have their MB info persisted, and an opt-in mechanism (like your added descriptor) would be needed. Otherwise, an opt-out (also using a descriptor) might make more sense. I could see a use for "transient" MBs that were never persisted in any way - I suppose there are many living in the JBoss Server now... It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle & persistence. Does anyone <cough>Juha</cough> know if this is likely? - Matt Munz -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Wednesday, October 02, 2002 12:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] creating persistent MBeans dynamically 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 ------------------------------------------------------- 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
