r394 should fix this. However, I'm unable to test it, because I'm running Oracle, and http://jira.rhq-project.org/browse/RHQ-160 prevents me from being able to upload a new package. Jess, would you please test this out on your system and let me know if it does the trick.

r395 refactors the impl slightly.

This smells kinda hacky. Why is there code specifically for updating resource versions in the content manager? 

That code should also move to inside of the CreateContentRunner thread. As it stands now, if this scan for some reason throws an error, the entire package deployment will be marked as failed, which shouldn't be the case. This should be handled in the same way as the package discovery scan, if this resource discovery should even be done at all.

Yeah, CreateContentRunner looks like a better place for it. And I guess simply logging an error if an exception occurs during the scan makes sense, otherwise the system's going to be in a different state than what we're telling the user. Also, hopefully the resource scan throwing an exception will be very rare.

As for whether the resource discovery should be done at all, if we want the resource versions to be updated, that's what needs to be done.

Ya, I see what you're saying about that discovery being necessary to get the resource versions updated. I'm just concerned it doesn't really make sense to hammer the agent with both a package and resource discovery for something that (arguably) only needs to be done for the JBoss patching use case. I'll give it some thought and move the call for it into the runner when I figure out what feels cleanest.

Making this critical since its dupe, RHQ-175, was

Maybe add a updatesResourceVersion="true" flag to either the install-package request or the metadata for the package type, and then only do the resource scan if that flag is set.

This also looks like it triggers a full discovery. Why didn't you scope the discovery to at least the resource type we know was affected?

Changed the issue entirely. After the initial posting, all of the comments/bug fixes were related to resource version updates. The original purpose of this issue was related to package versions on the resource, which is an entirely different issue. I'll create a new JIRA for that.

Original purpose of this JIRA captured in RHQ-185.

>> This also looks like it triggers a full discovery. Why didn't you scope the discovery to at least the resource type we know was affected?

Because if a CP is applied to an AS server, in addition to updating the server's version, it could theoretically also update the versions of child services - sort of similar to the cascading for package versions that RHQ-185 addresses.

Ah, ok. So am I reading this wrong or will this discovery also scan resources that are outside of that resource's hierarchy? I might be making too much out of this, trying to scope the discovery to the minimal scale it needs to be, but I'm still just not all that comfortable with the idea of having so many pieces start to move following a package deployment.

No, you're reading it right - the scans are not limited to that resource's hierarchy (but they are limited to its category and below). Hierarchy-limited scans would certainly be more efficient, but it would require adding new methods to the InventoryManager that support that, which I didn't think was worth doing for 2.0.

Ya, I agree that for now, it's not worth the investment to tweak the InventoryManager to have more flexible scanning.

r414 - Moved discovery logic so it doesn't interfere with the actual deployment request.

For now, going to leave the resource discovery as part of the deploy workflow. Going forward, this may end up changing in some capacity, potentially such as the resource discovery being triggered by package metadata.

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-179

*** Bug 535020 has been marked as a duplicate of this bug. ***