On subsequent updates of the EAR/WAR, only Version is prompted for, which is the correct behavior.
This may be due to trying to perform an update too soon after initial discovery. It takes some time to actually link the backing package to the resource. This can happen in a test scenario more likely than it would happen in the real world. Relevant chat: (11:54:32 PM) ips: i suspect this may have to do with the content package discovery scan not having run yet on the agent side for the ear and war resources that are showing the extra fields (11:54:51 PM) ips: in that case, the ears and wars would not yet be "attached" to their backing packages (11:55:38 PM) jshaughn: ips, that is possible (11:56:11 PM) jshaughn: there is a period of time that has to actually pass, if I recall, before the backing package can be identified for the resource (11:56:43 PM) jshaughn: the package discovery has to run. i remember writing tests that had to wait, sometimes quite a while (11:57:25 PM) jshaughn: from test_repoManager.js: (11:57:27 PM) jshaughn: // The backing package (InstalledPackage) for a new PBR may not exist immediately. It (11:57:27 PM) jshaughn: // requires an agent-side content discovery. Wait for up to 120 seconds (to take care of initial delay (11:57:27 PM) jshaughn: // and schedule interval timing. (11:57:37 PM) ips: content discovery runs every 30 seconds, but only does one resource at a time (11:58:29 PM) jshaughn: in my test I found that just about all 120 seconds were sometimes needed (11:58:50 PM) ips: so if there were 30 resources that implement the content facet, then it would take up to 900 seconds (15 mins) for the last packages to be discovered (11:59:21 PM) jshaughn: i'm not sure if it's sequential like that (11:59:47 PM) jshaughn: but possibly (6/10/2010 12:00:51 AM) ips: yeah, you're right, it uses a threa pool of size 10 (12:01:16 AM) ips: but each job is actually per resource/packageType tuple, not per resource (12:03:31 AM) ips: i could still see it taking 5+ minutes, depending on how many content supporting resources are in inv (12:05:02 AM) ips: well, i think users will only hit this if they try to update an ear or war shortly after that ear or war was discovered before the agent's had a chance to run content discovery for it (12:08:06 AM) jshaughn: ips. I think you're right about that update issue. that is exactly why I had to wait/sleep in the test script. I don't expect people will do that in reality. (12:08:25 AM) jshaughn: and it's not an easy thing for us to change, it's pretty much the design (12:09:41 AM) ips: jshaughn: yeah, i guess we could possibly not allow an ear/war resource to be updated until it has a backing package associated with it (12:10:13 AM) jshaughn: we could possible protect, but i think its unlikely to happen in a real scenario. (12:10:54 AM) jshaughn: but we could, I suppose check. the error message to the user would be weird, we'd have to just say "wait..."
There are a couple things we could do in the GUI if a content-backed Resource's backing package has not yet been discovered: 1) Show a message, perhaps on the Content>Deployed tab that says "This Resource's underlying WAR File package has not yet been discovered." This could be an informational message. Alternatively, if an exception occurred during the attempt to discover the backing package, the error could be displayed instead, e.g.: "While attempting to discover this Resource's underlying WAR File package, an unrecoverable error occurred: BlahException: blah blah blah" 2) Disallow uploading of new package versions via the Content>New tab, since the initial version of the package has not even been discovered yet. I would vote for doing 1).
I believe getBackingPackage will just return null if it can't find the BP for a given resource. We should probably put something in to just close this gap in the UI.
This may have improved with Stefan's overhaul a while back.