[from rhq-devel mailing list thread: https://fedorahosted.org/pipermail/rhq-devel/2010-October/000323.html ] On suggestion of heiko - I am posting here about a possible patch to InventoryManager - but not sure if it is a good idea. Adrian Brock and I (Michael Neale) have been using RHQ - lots of deployments/undeployments etc..: If you deploy UserDS-ds.xml then delete it (undeploy it). Then try to redeploy it, the inventory status stays at "DELETED" rather than going back to "COMMITTED". Running a full, manual, detailed discovery on the platform will fix the problem. So that might have to be our be our workaround until we can get a fix? I think Ive tracked the problem down to the InventoryManager, it is basically missing setting the inventory status when it already has the resource, but it is not in the state COMMITTED. public Resource mergeResourceFromDiscovery(Resource resource, Resource parent) throws PluginContainerException { // If the Resource is already in inventory, make sure its version is up-to-date, then simply return the // existing Resource. Resource existingResource = findMatchingChildResource(resource, parent); if (existingResource != null) { updateResourceVersion(existingResource, resource.getVersion()); + // proposed fix - make sure merged resources go back to committed + existingResource.setInventoryStatus(InventoryStatus.COMMITTED); return existingResource; } // Auto-generate id and auto-commit if embedded within JBossAS. if (!this.configuration.isInsideAgent()) { resource.setId(this.temporaryKeyIndex.decrementAndGet()); resource.setInventoryStatus(InventoryStatus.COMMITTED); This matches what used to be done in the old ResourceFactoryManagerBean.createInventoryResource() until that code was orphaned. Does this make sense at all?
This seems to make sense. However, I question blindly setting the status to COMMITTED. I'm thinking it might also be possible that the existing resource could be appropriately be in the NEW state - and in that case, setting it to COMMITTED here might be wrong. That's just a theory - I can't say for sure if, at this point in the code, the resource could be in any other state other than COMMITTED. We may need to put some kind of conditional around this, say something like: if (existingResource.getInventoryStatus() == InventoryStatus.DELETED) { existingResource.setInventoryStatus(InventoryStatus.COMMITTED) }
Do we know on what version of JBoss AS this is happening? I did some testing on 4.2.3, and everything looked ok. I also tested on 5.0.0.GA, and when I attempt to delete my data source from the UI, the request completes successfully; however, the actual data source does not appear to get deleted from the file system. I will have to look at the jboss-as-5 plugin to see what it is doing.
I believe this was with JBoss AS 4.2.3
*** This bug has been marked as a duplicate of bug 714812 ***