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
