persist & auto-restart mbean

[cnsxxx09]

Hi,

How can I persist my mbean's attributes and also get them to restart when JBoss restarts?

I'm *not* physically creating my MBeans and dropping them into the deploy/ directory.
Instead I'm dynamically creating one-to-many instances of the same MBean, as follows:

MyClass mBean = new myClass();
ObjectName objectName = new ObjectName("myserver.com:job=MyJob,id=" + myUniqueId);
server.registerMBean(mBean, objectName);

I schedule them (via Quartz web app) so I can have many instances in parallel.

I've seen that you need to change parameters in your descriptor files to make MBeans persistent - but as I create them dynamically I don't have descriptors.

Can someone point me to any examples of how to do this?

Similarly, when I restart JBoss (e.g. if my server crashes) my MBeans no longer exist. Is there any way to register them (as above) but telling JBoss to persist their existence?

Many thanks in advance!

Chris

[jiwils]

"cnsxxx09" wrote:
How can I persist my mbean's attributes and also get them to restart when JBoss restarts?

I'm *not* physically creating my MBeans and dropping them into the deploy/ directory. Instead I'm dynamically creating one-to-many instances of the same MBean

It is likely that you could just wrap your MBean/POJO class as an XMBean (pick one of the constructors), setup the "XMBean" to use a persistence manager, and then use the load method to get restoration of attributes. All of this could be done in the same class where the code you mentioned in your post lives.

We've looked into doing this in the past, and have plans to do just this in the future.

[cnsxxx09]

Thanks for the reply.

I've been searching the forums and web - and XMBeans does seem the way to go, but all the posts I have seen refer to setting the persistence within the descriptor (which of course I don't have). Doing the same thing 'in code' is a completely different kettle of fish, and examples are hard to come by. Have you come across any?

[cnsxxx09]

The problem I have is that I can't find code examples, all references I have found so far refer to thee descriptors being changed: e.g.

"If you want to load an existing Standard MBean as an XMBean .... then you obviously need to write an xmbean descriptor"

So, you don't need to change the Java code?

When I instantiate & register my XMBean (without descriptor) do I need to do something like:
server.registerXMBean ?
and something like,
server.getMBean().setPersistence(true)

any examples? maybe in JBoss' own source code?

[jiwils]

"cnsxxx09" wrote:
any examples? maybe in JBoss' own source code?

I don't have any example to give you, but using the javadoc for the JBoss org.jboss.mx.modelmbean.XMBean class, you can start looking at how to figure this out. The source for this class would be helpful to you as well I would think.

[cnsxxx09]

Thanks for the pointer ... I made some progress, I think.

Before I had my plain MBean registered and invokable.

Now, trying to use it as an XMBean, I have some kind of MBean registered which is not my class, and it has no methods/parameters to invoke/change.
I had expected it to just be like a wrapper to my class ... instead it is an empty wrapper ...

Any idea what step I missed?

I'm not sure I understand how it should work but I am expecting the XMBean to inherit everything from my MBean.

Here is my code:
work.MyClass mBean = new work.MyClass();
ObjectName objectName = new ObjectName("mydomain.com:job=MyJob,id=" +
System.identityHashCode(mBean));
XMBean xmbean = new XMBean(mBean, XMBeanConstants.STANDARD_MBEAN);

ModelMBeanInfo minfo = new ModelMBeanInfoSupport("work.MyClass",
"Uninitialized XMBean", new ModelMBeanAttributeInfo[0],
new ModelMBeanConstructorInfo[0], new ModelMBeanOperationInfo[0],
new ModelMBeanNotificationInfo[0]);

minfo.getMBeanDescriptor().setField(ModelMBeanConstants.PERSIST_NAME, objectName);
minfo.getMBeanDescriptor().setField(ModelMBeanConstants.PERSIST_POLICY, "OnUpdate");
minfo.getMBeanDescriptor().setField(ModelMBeanConstants.PP_NEVER, "false");
minfo.getMBeanDescriptor().setField(ModelMBeanConstants.PERSISTENCE_MANAGER, "org.jboss.mx.persistence.DelegatingPersistenceManager");

xmbean.setModelMBeanInfo(minfo);

server.registerMBean(xmbean, objectName);

invokeStringMethod(objectName, "setAStringObject", myStringObject);

[cnsxxx09]

Hi,

Further progress ... I managed to now get it registered as an XMBean.
But I'm b*ggered if I know how this auto-persistence is supposed to work ...
When you change an attribute in your XMBean using the jmx-console, shouldn't it now write something to $JBOSS_HOME/server/default/data/xmbean-attrs/
??
(I set persist policy to 'OnUpdate')

What's missing?

TIA

My new code:
work.MyClass mBean = new work.MyClass();
ObjectName objectName = new ObjectName("mydomain.com:job=MyJob,id=" +
System.identityHashCode(mBean));

Descriptor d = new DescriptorSupport();
d.setField(XMBeanConstants.RESOURCE_REFERENCE, mBean);
d.setField(XMBeanConstants.RESOURCE_TYPE, XMBeanConstants.STANDARD_MBEAN);
d.setField(ModelMBeanConstants.PERSIST_NAME, objectName);
d.setField(ModelMBeanConstants.PERSIST_POLICY, "OnUpdate");
d.setField(ModelMBeanConstants.PP_NEVER, "false");
d.setField(ModelMBeanConstants.PERSISTENCE_MANAGER, "org.jboss.mx.persistence.DelegatingPersistenceManager");

XMBean mmb = new XMBean(d, XMBeanConstants.DESCRIPTOR);

server.registerMBean(mmb, objectName);

invokeStringMethod(objectName, "setTestMethod", aTestValue);

[jiwils]

"cnsxxx09" wrote:
What's missing?

Good question...

You might try explicitly calling the store method on the XMBean you create to test the persistence. In the end, you will not need to do this, but you will need to manually call load in order to retrieve stored state.

[cnsxxx09]

It didn't work (running store() method), but I guess that when I do get all this working the load and store are done automatically by JBoss since I set a Persistence Manager in my descriptor ...
"XMBeans .. can specify a PersistenceManager (PM) that is used during XMBean instantiation to load any attributes previously saved, and during normal operation to save attributes, based on the chosen Persistence Policy."

Looking further into the documentation, and in particular comparing MBean XML descriptors to XMBean ones, I see that you need to specify a section of attributes. Presumably the PM uses this to know what to store or not.

If I'm right, I just need to learn how to add this into my code and then .. fingers crossed, it should work ...

(Of course, I still have the issue of wanting my instantiated XMBeans to restart when JBoss restarts ... but I'll save that for another post ...).

[cnsxxx09]

Hi,

When I use the twiddle command
$JBOSS_HOME/bin/twiddle.sh xmbean "mydomain.com:job=MyJob,id=xxx"
I get to see the XML config file for my dynamically generated MBean (nice).

Interestingly I see everything (operations, notifications, attributes) that JBoss has picked up from my MBean .... but, I don't see any reference to the descriptor and the fields that I set in my code before registering the XMBean (such as setting the persistence manager).

... and yet, it is within my descriptor itself that I am actually referring to the XMBean in question ... (as well as setting the persistence).

work.MyClass mBean = new work.MyClass();
...
d.setField(XMBeanConstants.RESOURCE_REFERENCE, mBean);

[dimitris]

Twiddle just prints out the standard MBeanInfo, not any potential extended information stored in there.

[cnsxxx09]

ok ...
My code just doesn't work then and I have no idea why.

As a test I used twiddle to print out the mbean info into an xml file.
Then I copied the persistent descriptor section from the JBoss persistent example sar directory into this same file.

I changed my code to read this XML file in instead, as follows:

work.MyClass mBean = new work.MyClass();
ObjectName objectName = new ObjectName("mydomain.com:job=MyJob,id=" +
System.identityHashCode(mBean));
XMBean mmb = new XMBean(mBean, "http://myhost.com/mbean.xml");
server.registerMBean(mmb, objectName);

and ... the persistence worked!!!!

Of course, it now means I have to maintain the descriptor as well as the code, which I shouldn't need to, but it allows me to move onto the next problem at least (and a new post/topic).