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.  The only flexibility to change this that I've found 
is the system property the specifies the required xmbean class.

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.

Third, the PM needs the objectName value of the bean to persist.  Might be missing 
something here as well.

Obviously, these issues can be resolved if we're able to modify the existing XMBean.  
I was going under the assumption that the PM I'm writing might not be merged into the 
CVS tree.

-------------

Why it's a problem if the server creates an MBean instance of it's own:

When the system starts up, the 'JMImplementation:type=MBeanRegistry' service is 
started with model mbean support.  Since the XMBean implementation creates an instance 
of the PM at creation time and the MBeanRegistry comes up before any other services, 
the persistence options are VERY limited.

If we could specify the PM to use on an XMBean by XMBean basis (I'm assuming in the 
descriptor here or maybe in the mbean tag if we want even finer control), the user 
would be able to make sure the services required by the PM itself were loaded before 
the service the PM is persisting.

-------------

What I mean by 'how this should be tied into the system?':

How we address the above issues.

-------------

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.

-- Paul


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

Reply via email to