Thinking about the DeploymentService and reviewing the documentation has lead me to the following conclusions:
1) The DeploymentService is a "good" fit for creating new, durable, services in JBoss. 2) The DeploymentService is an "ok" fit for updating services already created through the DeploymentService 3) The DeploymentService may not be a good fit for updating services not created through the DeploymentService, e.g. existing handcrafted -service.xml files Reasons for these conclusion: 1) See http://www.jboss.org/wiki/Wiki.jsp?page=DeploymentService for a description of how the DeploymentService offers a flexible approach to building deployment modules: .sar's, .war's, -service.xml etc. 2) If I understand correctly the process of updating a module with the DeploymentService involves making the following calls: a) undeployModuleAsynch(), passing in the module name to be updated b) removeModule(), passing in the module name to be updated b) createModule(), passing in the module name to be updated, template name and properties c) deployModuleAsynch(), passing in the module name to be updated Essentially an update via the DeploymentService is really a delete followed by a create. The corollary of this is that to update one property in a module all the others need to be provided as well. This is often not very difficult since most properties of modules are available through JMX, but sometimes, e.g. finding which driver is being used by a datasource, is more difficult. One option to alleviate this, which Dimitris has suggested, is to extend the DeploymentService by giving it a "memory" of the things which have been deployed through it. 3) To show why the DeploymentService may not always be a good fit for updating services it has not created let me give an example. The "default" JBoss configuration contains a file "deploy/hsqldb-ds.xml". This contains two things: the definition of the DefaultDS datasource and an MBean for the actual hsqldb instance. If I write a DeploymentService template for creating generic -ds.xml's it will not contain any knowledge of this special hsqldb MBean. If I then used it to update DefaultDS my updated hsqldb-ds.xml would not include the MBean for the hsqldb instance and by leaving out that MBean the module would no longer work as expected. This is an example of larger issue: given the fact that jboss-ds_1_0.dtd and jboss-ds_1_5.dtd allow arbitrary mbeans in a -ds.xml, we will never know precisely what a user will have put in their -ds.xml. Therefore the DeploymentService approach of updating (delete then create) may result in the loss of elements which it doesn't know about. This is obviously not an issue for modules the DeploymentService created since it knows the whole definition of what can exist in one of those modules. The above should be taken as my observations and is not meant as a critique of the DeploymentService since it was never designed to support option 3 above. I have just been investigating how far the DeploymentSerice will stretch. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863756#3863756 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863756 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
