Need DeploymentServiceMBean.updateModule() method

[peterj]

So far, the admin console project has been using the DeploymentServiceMBean.createModule() to define new data sources and JMS destinations to deploy.

Now, however, we need to modify existing configuration files located in other directories. For example, to modify the general JMS properties, we need to modify files such as server/xxx/deploy/jms/jbossmq-service.xml. In addition, we also need to be able to specify only those properties within those files that we want to change, and not replace the entire file, because the configuration file could contain other configuration information which the user might have made manually and does not want to lose.

Therefore, we propose a DeploymentServiceMBean.updateModule() method to provide this functionality.

One possibility for implementing such a method would be to use XSLT to modify and existing configuration file. We have developed a prototype that does this using the following steps:

1) The properties to be changed are supplied to a velocity template, which is used to generate a XSLT file
2) The XSLT file is then used to update an existing configuration XML file, with the result being a replacement configuration XML file.

You can access the prototype in Jira at http://jira.jboss.com/jira/browse/JBADMCON-79.

Of course, we are open to other possible solutions, but the bottom line is that we need a mechanism that enables the admin console to modify discreet properties within existing XML files.

[ccrouch]

Hi Peter
I noticed in the prototype implementation that instead of just specifying a Map of attributeNames to values for updateModule() to process, each attribute has an "operation" type e.g. add/update, which also needs to be specified.
This obviously requires clients to track what has happened to a particular attribute, e.g. store a copy of the original settings and then compare it to the intended new settings. Is there a way we could implement this without putting this requirement on the client, i.e. the client just passes in a map of attribute names to values and the updateModule() would figure out based on the contents of the configuration file whether an attribute is being added or updated? Also we would need to support removing attributes from a config file.

Thanks

[peterj]

I agree with you, Charles, it would too hard (if not impossible) for the admin console to determine if a property value is being updated or added. We are working on updating our prototype to handle this situation and will post it when it is complete.

[peterj]

One thing has been bugging me about this proposal for updating existing configuration files. In the prototype, one of the key pieces of information needed to update the properties of an MBean is the configuration file that defines the MBean. But the question is, how does one determine which configuration file defines a particular MBean? Especially if the configuration files could be named anything or appear almost anywhere.

For example, I renamed all of the JMS configuration files (e.g., hsqldb-jdbc2-service.xml became aaa-service.xml), renamed the jms directory, and even combined all of the configurations files into a single file (removing the rest), and in each case JMS was still functional.

So now, if the admin console changes, via the deployment sevice, one of the JMS MBean properties, how would the deployment service determine which XML file needs to be modified?

[starksm64]

A problem we have currently is the coupling of service definition with configuration without any mapping that defines how/where the configuration is defined such that there can be a decoupling.

[ccrouch]

"PeterJ" wrote:
But the question is, how does one determine which configuration file defines a particular MBean? Especially if the configuration files could be named anything or appear almost anywhere.

We do this for DataSources already. Take a look at org.jboss.admin.service.datasource.DataSourceServiceImpl.getDataSources(String dataSourceType). Essentially...

1) Given the ObjectName of a MBean you're interested in
2) Call listDeployed operation on jboss.system:service=MainDeployer Mbean
3) Loop over the returned collection of DeploymentInfo objects, if the DeploymentInfo.mbeans List contains the ObjectName you are interested then look at DeploymentInfo.url (maybe this should be DeploymentInfo.watch) to give you the location of the module.

The bigger issue is how the DeploymentService is currently "single-module" oriented, i.e. each call to the DeploymentService operates on one and only one deployment descriptor. This does not fit the JMS service very well since by default its key settings are configured across several modules.

Possible options...

a) Have the client of the DeploymentService maintain the linkage between each MBean and each module, so the client would do...
DeploymentService.update(module1, templateA, propertiesFromMBeanA)
DeploymentService.update(module2, templateB, propertiesFromMBeanB)
DeploymentService.update(module3, templateC, propertiesFromMBeanC)
...

If all the JMS MBeans are deployed in a single module then module1==module2==module3. The client would maintain the linkage by knowing the ObjectNames of the key JMS Mbeans (which it must do anyway to read the settings) and then use the procedure described above to determine the values of module1/2/3 etc. This algorithm could probably be done once per user session. Since each individual JMS MBean could potentially be deployed in a separate .xml file then DeploymentService.update() would need to be called once for each JMS Mbean that we want to support modifications to. Don't really like this solution since it puts a lot of onus on the client to keep track of deployment related things.


b) Have the DeploymentService take responsibility for mapping a single group of properties to multiple modules. At a minimum the client would still need to pass in additional meta-data about which property mapped to which MBean. The DeploymentService would then do the figuring out of which MBean mapped to which module. Don't really like this approach either, since currently the DeploymentService is not aware of the MBean's it ends up affecting, so adding that capability would reduce its cohesion somewhat.

[peterj]

Here is another possibility. Have the admin console always pass property values and a template for a single mbean to the deployment service. The deployment service could than look up the url for that mbeam, and update the corresponding configuration file. If the calls end up being are too fine grained (updating the JMS general settings could cause the update of multiple mbeans, and thus cause multiple update calls on the deployment service) perhaps an extended method that accepts a collection of template/property-value pairs could be passed.

[peterj]

I have placed an updated prototype into JIRA at http://jira.jboss.com/jira/browse/JBADMCON-79.

This prototype defines a template per MBean, and no longer requires the caller to know whether a property value is to be added or updated.

This is still a manula prototype with Ant calling Java code and and a program to generate the final XML file. Up next is to provide a proposed change to the deployment service itself.

[peterj]

Yet a third prototype, updateMBean.zip, has been placed at http://jira.jboss.com/jira/browse/JBADMCON-79. This prototype uses a generic Velocity template to generate an XSLT that can be used to update a specific MBean in an existing XML configuration file. The example provided with the prototype updates two MBeans is a single XML configuration file.

In addtion, the prototype no longer relies on a Windows command line tool to perform the XSL transform, so it will work on any platform. If you want to try it out, make sure you update the build.properties file first.

[peterj]

I finally have the patch for the deployment service to support an updateMBean method. The suggested patch, and a a simple client that invokes updateMBean, can be found at http://jira.jboss.com/jira/browse/JBADMCON-79 in the updateMBean.zip file. See the included readme.txt file for instructions.

My next task is to develop unit tests for this functionality. But I would like to get this patch put into the deployment service as soon as possible so that we can continue work on the admin console.

Note that the code is very much based on the last prototype, with a Velocity template being used to generate an XSLT which is then used to udpate the XML config file that contains the MBean.

I tried to use existing code to do both the Velocity processing and the XSL tranfrom (the later required that I package more class files in the deployment service JAR file). I also followed the existing pattern used to define the Velocity templates.

I used the MainDeployer MBean to locate the configuration XML file for a given MBEan (see the configPathFor() method). I am not sure if I should have used a more direct approach for that (nor could I figure out a more direct approach).

Also, I have quite a bit of logging info being generated at this time, which I will remove before I check in the changes. I will also change the way I do in-line comments, I just now noticed that I didn't follow the existing coding standards for those.

Charles, do you know if there is a JIRA issue against the deployment service already to support updateMBean? If not, I will create one in the JBAS project so that I will have a JIRA issue to reference when checking in the patch.

[peterj]

I finally create a JIRA issue for this item (JBAS-2580).

I was going to work on a set of test cases before checking in the patch, but I am a little stumped. I checked through all of jboss-head and could not find any existing test cases for the org.jboss.services.deployment.DeploymentManager class or the org.jboss.services.deployment.DeploymentServiceMBean interface. I was hoping to simply add new test cases to existing tests, especially since I am not clear on wherether it is even possible to test this functionlaity ourside of a running server instance.

Any enlightenment and suggestions would be helpful.

[ccrouch]

Take a look at

jboss-head\testsuite\src\main\org\jboss\test\deployment\test\DeploymentServiceUnitTestCase.java

for the existing tests.

Cheers

[peterj]

For those not watching JIRA, a patch has been submitted to jboss-head, including a set of unit test cases.

[peterj]

I have been looking at updating pre-existing data sources using the deployment service, and of course ultimately the admin console. Usually, this would concern DefaultDS, but could also concern data sources created by copying the *-ds.xml file into the deploy directory (I know I do that quite often for my applications).

It seems to me that the most sane approach to this is to enable the pre-existing data source to be undeployed and then deleted (if so desired), and then create a new data source. Thus making handling of pre-existing data sources the same that of data sources created via the deployment service.

I have created a unit test to try this out and it works.

Anyone have any reasons for why updating pre-existing data sources should not be done in this fashion, please speak up now.

At this point the only additional change I plan to make to the deployment service in this regard is adding the additional unit test. The admin console team can then modify it to enable editing of pre-existing data sources.

[ccrouch]

The problem with using the standard delete/create cycle for updating existing DataSources is that all mbeans which are deployed along side the DataSource in the -ds.xml well get removed during the "delete" phase and will not get regenerated during the "create" phase. For example in hsqldb-ds.xml the following mbean is deployed along with the DataSource definition:

<mbean code="org.jboss.jdbc.HypersonicDatabase"
 name="jboss:service=Hypersonic,database=localDB">
 <attribute name="Database">localDB</attribute>
 <attribute name="InProcessMode">true</attribute>
 </mbean>

As it stands now using the deployment service to update the DefaultDS in hsqldb-ds.xml would result in the above mbean being lost.

Thanks