Regarding JIRA issue JBADMCON-134. One of the variations on updating a data source is removing the data source. For a data source created by the admin console, or other tool, via the deployment service, deleting is simple - just call undeployModule and removeModule. For an existing data source that doesn't work, however, because the -ds.xml file is not in the location expected by the deployment service.
Several possibilities exist for deleting and existing data source.
1) Handle delete just like update. That is, create xslt templates that will remove the data source definition from a -ds.xml file, much the same way that updateDataSource is currently updating the data source node within an existing -ds.xml file. The advantange of this method is that any mbeans declared within the -ds.xml file will remain in effect. The disadvantage is that if said mbeans depend on the data source just deleted, then those mbeans are useless. Or, if there is no other information in the -ds.xml file, then an essentially empty file will be cluttering up the deploy directory.
2) Delete the -ds.xml file that declares the data source. The disadvantage is that this also removes any mbeans declared in that file. However, I would propose that we actively discourage mbeans that are not data source related from appearing in a -ds.xml file. Another possibility is if someone declared multiple data sources in the same -ds.xml file, then they would all disappear. Once again, I would discourage such usage. (I have never done this, so I don't know if it is even possible and any documentation I have seen on data source has one per file.)
3) Examine what removing the data-source node from the -ds.xml file will leave behind. If the resulting file is empty, remove it, otherwise just remove the data-source node from the file via an xslt template. This removes one of the objections to option 1 (empty files after data source delete) but not the other (for hsqldb-ds.xml, you are left with a useless mbean).
Options 1 and 2 are easy, option 3 will take a bit more work (probably opening the -ds.xml file and noting all of the second-level nodes).
Currently, I am leaning toward option #2.
Thoughts and comments are welcome.