Re: [JBoss-user] XMBean Persistence
Well, I understand what you are saying, for me I wanted to write even one xmbean descriptor by hand so little that I wrote the xdoclet task first;-)) david jencks On 2002.08.19 09:41:29 -0400 Matt Munz wrote: > David, > > > Do you know about/are you using the xdoclet xmbean stuff to generate > your > > xmbean xml descriptors from annotated source code? > > Yes, I'm aware of this. No, I am not using it. > > xdoclet sounds useful. I try to get familiar with the code before I > start > using code generation tools, so I don't imagine I'll be looking at > xdoclet > for a while ;) > > - Matt > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks > Sent: Saturday, August 17, 2002 10:56 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] XMBean Persistence > > > On 2002.08.17 21:03:41 -0400 Matt Munz wrote: > > 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. ;) > > I'm not 100% sure, but I think the same persistence stuff should work for > any mbean. We'd just need to get the appropriate persistence interceptor > into the default for standared mbeans. > > Even if it doesn't, I think we will be moving everything to xmbeans > anyway, > I hope soon. At the minimum it provides the ability to document > everything > in the ui. > > Do you know about/are you using the xdoclet xmbean stuff to generate your > xmbean xml descriptors from annotated source code? I think its used in > the > xmbean test case in test/jmx... If not, I generated the descriptor using > it. > > Thanks > david jencks > > > > - 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. > >
RE: [JBoss-user] XMBean Persistence
David, > Do you know about/are you using the xdoclet xmbean stuff to generate your > xmbean xml descriptors from annotated source code? Yes, I'm aware of this. No, I am not using it. xdoclet sounds useful. I try to get familiar with the code before I start using code generation tools, so I don't imagine I'll be looking at xdoclet for a while ;) - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Saturday, August 17, 2002 10:56 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] XMBean Persistence On 2002.08.17 21:03:41 -0400 Matt Munz wrote: > 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. ;) I'm not 100% sure, but I think the same persistence stuff should work for any mbean. We'd just need to get the appropriate persistence interceptor into the default for standared mbeans. Even if it doesn't, I think we will be moving everything to xmbeans anyway, I hope soon. At the minimum it provides the ability to document everything in the ui. Do you know about/are you using the xdoclet xmbean stuff to generate your xmbean xml descriptors from annotated source code? I think its used in the xmbean test case in test/jmx... If not, I generated the descriptor using it. Thanks david jencks > > - 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.m
RE: [JBoss-user] XMBean Persistence
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 expl
Re: [JBoss-user] XMBean Persistence
On 2002.08.17 21:03:41 -0400 Matt Munz wrote: > 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. ;) I'm not 100% sure, but I think the same persistence stuff should work for any mbean. We'd just need to get the appropriate persistence interceptor into the default for standared mbeans. Even if it doesn't, I think we will be moving everything to xmbeans anyway, I hope soon. At the minimum it provides the ability to document everything in the ui. Do you know about/are you using the xdoclet xmbean stuff to generate your xmbean xml descriptors from annotated source code? I think its used in the xmbean test case in test/jmx... If not, I generated the descriptor using it. Thanks david jencks > > - 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. Mod
RE: [JBoss-user] XMBean Persistence
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 l
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? > > > &
RE: [JBoss-user] XMBean Persistence
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(); 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? Am I on the right track here, or is the "persistence" instance variable on org.jboss.mx.modelmbean.ModelMBeanInvoker a "canard"? - 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
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
[JBoss-user] XMBean Persistence
(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
