The JBoss service deployment system really only works for standard and dynamic mbeans at the moment. We want to convert it (I think in 3.1) to use all xmbeans, which will then have the persistence capabilities you mention.
Is this what you are talking about?
Ambiente, implement it :) you will get RW
Hmm, I didn't see marc's invitation before implementing and committing basic xmbean deployment from *-service.xml files. However, there is still lots to do - in fact the hard part.
The testcase (org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) deploys an mbean whose dd is generated by xdoclet. The bean deploys successfully but very little of the interface works. Most of the attributes aren't visible or settable. The operations appear to work, however. I don't know if the persistence mechanism is in a very usable state either.
One of the desirable consequences of having the code attribute of the mbean element in *-service.xml be the class name of the object you wish to manage is that if the class is not available the mbean will participate in the mbean-class dependency tracking.
I just committed a patch that makes the attributes
work for JBossXMBean.
It is a not very well explained feature of ModelMBean
that the get/setMethods have to be management operations.
I'm no expert on XMBean, so I'm not sure if my patch
is the correct way to do this.
Juha was talking about having getter/setter descriptors.
Anyway, my patch isn't bullet proof. I'm not checking
the access or impact attributes. Also, I think you
restricted the method names to the java bean standard,
something I haven't assumed.
> Hmm, I didn't see marc's invitation before
> implementing and committing basic xmbean deployment
> from *-service.xml files. However, there is still
> lots to do - in fact the hard part.
> The testcase
> deploys an mbean whose dd is generated by xdoclet.
> The bean deploys successfully but very little of the
> interface works. Most of the attributes aren't
> visible or settable. The operations appear to work,
> however. I don't know if the persistence mechanism
> is in a very usable state either.
> One of the desirable consequences of having the code
> attribute of the mbean element in *-service.xml be
> the class name of the object you wish to manage is
> that if the class is not available the mbean will
> participate in the mbean-class dependency tracking.
May be I am wrong, but it seems to me you meant different thing. What I had in my mind was the following:
Say I developed simple static MBean and packaged it to .sar file (and of course included jboss-service.xml with relevant 'mbean' tag). Now when JBoss deploys such mbean it will create and register XMBean instance for the above mentioned MBean which will allow to handle configuration persistency automatically. In other words creation of my MBean will be substituted by creation of XMBean instance which will handle all management operations on my MBean. At first glance it can be achived by changing the way MBeans are created in org.jboss.mx.server.MBeanServerImpl class where method instantiate is responsible for mbean creation. This can be altered so that custom classes, responsible for MBean creation can be plugged into. One of such 'creators' can be implemented so it substitutes creation of MBean by the creation of XMBean. May be there are better ways of achieving this, I'm just not quite familiar with JBoss sources. Another good thing to have would be ability to register custom PersistentMBean implementations to control the way MBean configuration is stored. Again, not being familiar with JBoss sources I might be talking about things which are already implemented. Could someone clarify this, please?
OK, I think we were talking about somewhat different things. I think you want a standard persistence policy for standard (and dynamic) mbeans, and to be able to swap persistence implementations.
I think you can set this up today in jbossmx using the mx interceptor stack, but I'm not sure where this is configured.
I think there is a problem however. Right now we are really using the *-service.xml files for 2 purposes: initial configuration and persistence. So, to work around this, we undeploy everything as jboss shuts down. On restart, we deploy every *-service.xml file we find. How will persistence fit into this scheme? Right now, I would expect a conflict on restart between the *-service.xml configuration and the persisted configuration for the same mbean. Which wins???
One solution might be to make the DeploymentInfos into persistent mbeans, recording the timestamp from the *-service.xml file. On restart, first all the persistent mbeans are read in from storage, including the deploymentinfo mbeans. The deployment scanner will compare its recorded timestamp with the actual timestamp of the *-service.xml and redeploy if it has changed.
Actually writing this down it seems like it might be pretty easy to implement.
David, Thank you for pointing out about mx interceptors, I will look into it. As to the configuration and persistence conflict you mentioned I think the following policy might be applied - if persisted configuration is available then it should be used, if it is not available then JBoss will use what is provided in *-service.xml file. You also mentioned *-service.xml is used to handle persistence. What did you mean by that?
I'm not sure how to explain what I'm thinking. I can't decide if it is really confusing or fairly obvious or both;-) (or if I need more coffee)
If you start from the point of view that in order to have consistent server state between server runs the mbean state must be persisted somewhere, and ask where the mbean state is currently persisted, the answer is "in the *-service.xml files". Of course, this answer is misleading, because the *-service.xml files are not updated when you change an attribute in the jmx server.
If we start persisting mbeans and using the saved config when restarting the server, we have to be very careful because there are then 2 copies of config for each or most mbeans: the one from the original *-service.xml and the saved one. Figuring out which is the one to use is a little tricky.
Lets suppose we have a my-service.xml with one mbean, jboss.my:name=mine with one boolean attribute value, originally set false in my-service.xml
1. deploy my-service.xml, change value to true, shutdown and restart jboss, value should be true from saved state.
2. deploy my-service.xml, shutdown jboss, change my-service.xml to indicate true, restart jboss. Value should be true from saved state.
3. deploy my-service.xml, change value to true, shutdown jboss, touch my-service.xml to indicate we want value false again, restart jboss, value should be false.
4. deploy my-service.xml, shutdown jboss (the mbean state is now saved), remove my-service.xml, restart jboss. The mbean should not be deployed (even though saved state is present) or should be deployed then immediately undeployed.
I _think_ these cases would be handled correctly by making DeploymentInfo into an mbean and persisting its state. Did I miss any cases?
Well... You might be right, but I'm thinking... perhaps all configuration activities should be done via JMX and not manually (by correcting *-service.xml file for instance) so that it is always reflected in persisted configuration information. I think it is more consistent than taking configuration from two sources (depending on some criteria)... I do understand that sometimes it is nessesary to take configuration information which is provided in *-service.xml... may be it's better to somehow let JBoss know that persisted configuration should be ignored. I can't figure out what's better yet.
the persistent mbean state needs to be separated from the server configuration (which is the set of mbeans that compose the server)
that is your "default setup" ala windows with your default values.
with versioning persistence on the state you get also the "last known working configuration" ala windows.
Yes you are correct, the xml files used were incorrect if they did not create descriptors to map to accessor operations. Maybe your change is better though if it confuses less people. It should be documented in the DTD.
Anyway, I plan on redoing the DTD for 1.2. After trying to write an xml definition for registry made me realize the 1.0 version needs to be improved.
> I just committed a patch that makes the attributes
> work for JBossXMBean.
> It is a not very well explained feature of
> that the get/setMethods have to be management
> I'm no expert on XMBean, so I'm not sure if my patch
> is the correct way to do this.
> Juha was talking about having getter/setter
> Anyway, my patch isn't bullet proof. I'm not
> the access or impact attributes. Also, I think you
> restricted the method names to the java bean
> something I haven't assumed.
I'm not understanding what you guys are talking about
1. You have to start somewhere, I think that is going to be a bunch of *-service.xml files for a long time to come.
2. I don't think it is reasonable to say "even if you change the *-service.xml file, once it is deployed all changes have to be made directly through the jmx server"
Today, there are 2 ways to change the configuration, directly through the server or by changing *-service.xml files. Right now, only the second method persists over server stop/start. I think this discussion is how to make direct changes to mbean configuration persistent over server stop/start without breaking the ability to change the state through the *-service.xml files and without confusing people too much. (e.g. as we did with jboss-auto.jcml)
Totally agree with both of your points. Your further note is also relevant. My initial question was how to provide configuration persistence for MBeans in a manner where MBean developer does not have to think about it meaning that developer simply exposes management interfaces through MBean interfaces and the rest is performed by JBoss. I thought this was where ModelMBean interface and particulary XMBean class (which I think is quite valuable) help and this is why I asked whether it was possible to substitute MBean instantiation by instatntiation of the XMBean class through wich all MBean management operations would be performed. May be I am missing something or it has already been implemented but it's an open issue for me after having look at JBoss, MX4J, Tivoli and Weblogic. Looks like JBoss might be most suitable for that without writing code which would be specific to some JMX implementation.
yes, persistence interceptor (an incomplete proto is in the cvs) plus persistence manager implementations (interface is there, no implementations) is what you are looking for.