WLST and delete problem

Question

I've got two WLST scripts, one that creates a number of different resources (JDBC DataSources, JMSModules etc..) and one that deletes those resources. I'm running this against a 10.1 WLS
As I'm developing the script, I invoke the create scrip, check the server to see that the artifacts have been created, then invoke the 'drop' script which calls delete() to remove the artifacts.
The problem I'm seeing is that the drop script doesn't really seem to delete the artifacts. While they don't show in the console (i.e. I can navigate to the DataSources page and see it missing), the they still seem to be in the JNDI tree... even though all my changes are activated.
So, on subsequent invocations of my create script I get BeanAlreadyExists exceptions.
What am I missing here....
Thanks in advance,
Bruce

Answer 1

Hi Charles,
Thanks for trying this..
To potentially complicate this a bit more (maybe) I think it might be related to the problem described here:
delete JMS module does not clean up resource descriptor file
Specifically, one of the resources I'm trying to delete is a JMS Module. So the sequence of operations is:
0) I invoke a WLST script to create JMS Module and JDBC DataSources
1) Invoke WLST script that tries to delete() a JMS Module and JDBC DataSources (then save/activate)
2) I get an exception that reads something like:
Attempt to operate 'remove' on null BasicDeploymentMBean : ... [says something about needing to restart WLS]
3) I restart the WLS, open the admin console, the Activate button is green and I and invoke Activate from the console. I get no errors or warnings.
4) Inspect the JNDI tree and see the JMS DataSources still present in JNDI tree in spite of them being missing from the Data Sources page on the console
5) I notice the resource descriptor files for both JMS Module and JDBC DataSources remain under the config/jms and config/jdbc directories on the file system. It also look like they are still in
6) If I shut down the WLS server and restart JDBC data sources still in JNDI tree
If I shut down and restart the server between step 0) and 1) then I don't get the exception mentioned in step 2) and the delete really appears to take place.
-Bruce