On Wed, 26 Jun 2002, Paul Ward wrote: > Why I had to create an XMBean descendant: > > First, XMBean's link to the PM interface is through the instance created in the >static > initializer for the ModelMBeanInvoker class. This class is hard coded to use the >NullPersistence > class as it's PM.
True, as we don't have any PMs yet. Just change this implementation to allow you to configure any PM. > Second, the PM needs a reference to the XMBean instance so that it may > call the MBeanInvoker.getAttribute and MBeanInvoker.setAttribute > methods. It is not practical to try and access the attributes through > the stack since we'll need to restore the values before the mbean is > registered with the server. Maybe I'm missing something here about > another way to access the mbean attribute values themselves. We will make the callback to load() as part of the MBean's registration phase, after the interceptor stack has been properly set up (rather than making the completely brain dead load() in the constructor which is what the spec mandates). Therefore it might be worth it to change the PM interface to contain a reference to the invoker directly rather than to the metadata (which will be available through the invoker) and therefore you will have direct access to the set/getAttribute as well (with properly working stack by the time your load() is called). > Third, the PM needs the objectName value of the bean to persist. > Might be missing something here as well. This will also be available through the MBeanInvoker interface. I will commit these changes in about a week to the CVS. > Obviously, these issues can be resolved if we're able to modify the existing XMBean. You are. > I was going under the assumption that the PM I'm writing might not be merged into > the CVS tree. You're the first one wanting to take a stab at it. I will get you a CVS RW. > If we could specify the PM to use on an XMBean by XMBean basis Yes that is the idea. > (I'm assuming in the descriptor here or maybe in the mbean tag if we > want even finer control), Yes. > What I mean by 'how this should be tied into the system?': > > How we address the above issues. Go ahead and make the changes directly to the XMBean implementation. There are some changes coming to the invoker/invocation though. I will commit these by the end of the month. You might want to wait for those to appear first. > BTW, I have the implementation up and running. The user must not specify > the default values in the jboss-service.xml though, since doing so persists > the default values right over top of the values persisted on the last > server run. Any insight you could provide to address this issue would > be appreciated. I don't know how jboss-service.xml works. -- Juha ------------------------------------------------------- This sf.net email is sponsored by: Jabber Inc. Don't miss the IM event of the season | Special offer for OSDN members! JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
