The resource name is repopulated, however the package name and file are not. I suspect the architecture isn't either; it's harder to see since it's a drop down box. These should be repopulated since it's a "resubmit". I think the file will be tricky to repopulate; that component is a bit weird to work with. The package name will also be tricky, since it's not currently stored in the create resource audit entity. Same for architecture. It used to be; the code for the resubmit even contained a call to get the package name (it was commented out). I forget why that was removed from the entity.
There is no place in the history entity to save this information. I'll have to reacquaint myself with the model to remember why. One possibility is to snap out an installed package history (read: package audit trail) entry for this. That won't save the file name (I'm actually reasonably ok omitting this) but will have the PackageVersion and thus the package name. The UIBean will then know this entry will be there and pop off the necessary data.
The installed package history entity will also give us the architecture information. The more I think about this, the more I like this approach. In fact, I'd argue the lack of it is a bug in its own right; even though this falls under resource create, it is still a package creation operation.
This is going to be uglier to fix than I wanted. Currently, InstalledPackageHistory (i.e. the audit trail entity) has an optional reference to the ContentServiceRequest (hereafter CSR) that caused it. The optional part is due to account for discoveries where there was no request. Creating a package-backed resource doesn't snap out a CSR; all of the history tracking is done in the create resource history entities instead. It's always been a separate subsystem despite the fact that both are, in a way, related to packages. There really isn't much cross over logic between the two subsystems to gain from going out of our way to link them, short of the the server-side history tracking (which is the issue in the discussion that follows). On that note, one solution would be to have multiple request history entries: one for the create resource request and one, associated with that, for the content creation request. That way, if the user views the history of all content operations on a resource, it will also show that there is a content deploy in progress while the resource creation is taking place (in a way, it's a duplicate request from the create resource one, but makes sense as two different things). This makes sense since if I'm deploying an EAR and a library at the same time, they are both content deployments, regardless of the fact that the EAR one is also creating a resource at the same time. The drawback is that we will have to do some special processing to prevent the content UI from being able to resubmit that content request; the user should do it by resubmitting the failed resource create instead. This may prove confusing. Getting back to the desired goal of having the audit trail entry available, this would give me a place to hang it in the existing database model for the audit trail. I'd still need to change the requests to associate the content request with the resource create request, but that's not killer. I'm not in love with this approach. I'm going to give it a bit to sink in before I proceed.
Solving this logging issue (or choosing not to) is part of RHQ-504.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-490 This bug is incorporated by RHQ-504
*** Bug 536066 has been marked as a duplicate of this bug. ***
Triaged 5-Oct