Adrian, Is there any code I could see / use as a starting point?
David, Thank you for your suggestions. I will definately look into implementing the mechanism you describe. > Out of curiousity, what are you using xmbean persistence for? Generally, I'm trying to deliver a modular, reconfigurable, J2EE-based server product that is easily maintained and configured. I'm currently not interested in the EJB elements of J2EE, and JMX seems to be the most valueable part of the JBoss feature set for me right now. Basically, I want the deployer to be able to drop in an unconfigured or minimally configured server module and then configure it via the (JMX) management interface. In the spirit of efficiency, I want these changes to be permanent. That way, if the deployer needs to re-start the server, the server configuration isn't lost. What makes XMBean persistence great for this is that it is sufficiently generic to be useful in most if not all cases, without the need to write custom persistence code for each managed object. At some point, it might be interesting to extend persistence to all MBeans on the server, allowing one to make a "snapshot" of the current configuration. That snapshot could be reloaded at some point in the future to return the server to its prior configuration. This isn't on my radar, however, as, based on my experiences with standard and dynamic MBeans, I don't expect I'll be using them. ;) - Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, August 16, 2002 9:19 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] XMBean Persistence On 2002.08.16 15:47:05 -0400 Matt Munz wrote: > David, > > Thanks for your reply. Could you indulge me in some additional > information? > > I am fuzzy on the interceptor stack concept, and I don't see how > persistence is currently implemented as a "stack" or "interceptor". I > found > the following line in org.jboss.mx.modelmbean.ModelMBeanInvoker. > > protected PersistenceManager persistence = new NullPersistence(); Hmm. probably not much persistence from that one;-) > > ModelMBeanInvoker is the superclass of org.jboss.mx.modelmbean.XMBean. > At > deploy-time, the server parses my jboss-service.xml and creates a new > instance of org.jboss.mx.modelmbean.XMBean, using the xmbean descriptor > (xml) that I provide. > > When I set values on my XMBean, the NullPersistence (Manager) is > called, > which (as its name implies) does nothing. > > What I'm thinking of doing is writing a FileBasedPersistenceManager or > JDBCPersistenceManager or a similar class. Then I'd create a way to > designate this in the *-service.xml or XMBean descriptor xml. Then the > object that instantiates the MBean can set its PersistenceManager to a > non-null type. > > I got the impression that someone had already done this, or something > equivalent. Is this true? Adrian is working on it as I understand. > > Am I on the right track here, or is the "persistence" instance variable > on > org.jboss.mx.modelmbean.ModelMBeanInvoker a "canard"? OK, I just looked through the code, and discovered I didn't know how this is set up:-) here's what I now think you should do: 1. implement your persistence stuff as a PersistenceManager. 2. add a descriptor (and parsing for it) to the xmbean10 xml/dtd that identifies the class of your persistence thingy. Make XMBean10 find this and turn it into a descriptor (you can use the generic descriptor method, but I think this should explicitly named). 3. Modify ModelMBeanInvoker.preRegister to look for this descriptor (parsed for you by XMBean10) and if found create an instance and install it as the persistence for that mbean. If you need a lot of parameters for your PersistenceManager I'd think about making it into an mbean and supplying the ObjectName in the descriptor. I'd probably include a getInstance managed attribute/operation so the actual object can be retrieved.... no need for an interceptor stack for to the persistence manager;-) 4. Contribute the results. I'd really like to see this working. I think it will eventually revolutionize jboss administration, although it might take a big change in attitude. Out of curiousity, what are you using xmbean persistence for? Thanks! david jencks > > - Matt > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks > Sent: Friday, August 16, 2002 2:55 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] XMBean Persistence > > > everything I have done is in cvs head. I think there is a xmbean > persistence interceptor in the interceptor stack, but I have never looked > at it. > > My latest changes in this area: > > --xmbean xml descriptor can include initial values for attributes. They > are set from string representations using PropertyEditors, just like in > ServiceConfigurator. > > --(not part of jbossmx, but related) You can directly include an xmbean > xml > descriptor in a *-service.xml file and it will be loaded as with any > other > mbean. > > Previous related work: undeploying a class that is used for an mbean > results in the mbean being undeployed and its current attribute values > saved in a normal -service.xml snippet. When you resupply the class, you > get the mbean back with these values. This almost certainly doesn't work > with xmbeans, just standard and dynamic mbeans. > > If this is insufficiently detailed let me know. > > thanks > david jencks > > On 2002.08.16 14:30:28 -0400 Matt Munz wrote: > > > > (this is copied from a forum topic by the same name) > > > > Paul, Juha, David, Sacha, and others, > > > > I have been following your threads (mail and forum), and have come to > the > > conclusion that I am one step behind on this issue. > > > > I need to get minimal XMBean Persistence working ASAP and am happy to > > write > > the code to do so. Based on your comments, I think at least one of you > > may > > have already done this. > > > > Would it be possible for me to see the code? > > > > If not, any pointers on getting started with implementing this? > > > > - Matt > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: OSDN - Tired of that same old > > cell phone? Get a new here for FREE! > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
