Hi Matt,

>From: "Matt Munz" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: RE: [JBoss-user] XMBean Persistence
>Date: Sat, 17 Aug 2002 21:03:41 -0400
>
>Adrian,
>
>   Is there any code I could see / use as a starting point?

The changes David suggested sound ok.
I think this was how Juha intended this to work.

The changes I will be looking at (not there yet) is the part not on
your radar. This should also include distributing changes throughout
a cluster without having to change the deployment descriptor and
re-farming the deployment.
Local Persistence is still relevent for individual machine tuning.

The actual persistence mechanism (PersistenceManager) is irrelevent
to me. I don't really think these implementations belong in the
jmx layer.

Regards,
Adrian

>
>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


_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com



-------------------------------------------------------
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

Reply via email to