Juha, > what you need to persist from the registry is the information to > recreate the mbeans
OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). >> here. Incidentally, it appears to indicate that the entire MMB (MMB info >> and data) should be persisted at store(). > > no, just the state of the attributes (or diff update on one changed > attribute, actually)... imagine an ON_UPDATE policy > writing the whole metadata down to storage every time, doesn't make sense. Could you clarify the following from P. 87 of the spec? "store Writes the MBean in a persistent store. Should only called by an implementation of the ModelMBean interface to store itself according to persistence policy for the MBean. When used, it may be called with every invocation of setAttribute or on a periodic basis. (optional)" If "the MBean" is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense, especially considering the fact that dynamic changes to the MBeanInfo are ignored by the server. Perhaps this sentence should be re-written? >> 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? > > there doesn't seem to be much interest in that at the moment > > on the other hand it gives us the freedom to write implementations that > make sense Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) - Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Wednesday, October 02, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Wed, 2 Oct 2002, Matt Munz wrote: > 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). no, the individual mbeans already persisted their state they need on their own, what you need to persist from the registry is the information to recreate the mbeans (who will then go an load() their own state they already persisted), ie which constructor to use at startup, what args go into the constructor > 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? I think you're confusing the two different modes of persistence: say I registered an XMbean instance from location http://foo/bar.xml (which is my mbean definition). When you register this mbean to the registry you pass in the valueMap that info, <init>(URL) was used with arg http://foo/bar.xml + objectname blah. Registry stores this info as part of its own state. When registry is recreated (server restart) it goes to its own persistence location and gets this info, calls the constructor, creates the new mbean instance, bar.xml has the persistence info for the mbean and the bean will load() its own state. > 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(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. > 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? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense -- Juha ------------------------------------------------------- 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
