Bug 749804 - Updating an existent EAR/WAR to new location deploys properly but displays in UI incorrectly
Updating an existent EAR/WAR to new location deploys properly but displays in...
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
3.0.0
All All
high Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On: 752918 752919 752920 752921 752925 752926 752928 752929 753761 672240 752761
Blocks: jon30-sprint8
  Show dependency treegraph
 
Reported: 2011-10-28 09:38 EDT by Robert Buck
Modified: 2011-11-16 16:03 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 672240
Environment:
Last Closed: 2011-11-16 16:03:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Robert Buck 2011-10-28 09:38:50 EDT
+++ This bug was initially created as a clone of Bug #672240 +++

I am not seeing quite the same thing as #672240, but what I see is this, and perhaps a different bug:

1. deploy helloworld.zip to no1/deploy/hellof (assuming this were a typo)
2. purge that deployment
3. verify it no longer exists on disk and that helloworld no longer is running
4. redeploy to no1/deploy/helloworld
5. navigate to the resource for helloworld.war at
http://localhost:7080/coregui/#Resource/11275/Inventory/ConnectionSettings
6. under helloworld.war resource look at the connection settings, it still says
"/home/rbuck/dev/servers/jboss-as/4.0.3/jboss-4.0.3SP1/server/no1/deploy/hellof/helloworld.war"
as the path even though it was successfully redeployed elsewhere.

What I would expect is that the Pathname/Filename for the resource should reflect the new path, not the old path. It presently shows the old path while having successfully deployed to the correct location.
Comment 1 Ian Springer 2011-11-10 11:19:48 EST
The absolute path to the warfile is used as the Resource key for WAR Resources (see ApplicationDiscoveryComponent). So if you deploy a war to a new path, it will be rediscovered as a new Resource with the new path as the key. The old war Resource will remain in inventory until uninventoried by the user, but it will have an avail of DOWN if the war is no longer deployed to the original location.

Resource keys generally do not change. The only exception is if a resource key is changed by the plugin due to a change in key format in a new version of the plugin (see ResourceUpgradeFacet in plugin API), but this is not the case here.
Comment 2 Heiko W. Rupp 2011-11-14 11:46:59 EST
I agree with Robert, that this is sort of annoying.
There is the workaround of unimport/import for this scenario.

Also as application servers could have multiple war files with same names in different directories, RHQ can't just if it sees one go away take the next and hope that this is a redeploy of the other.
Also automatic unimport is not desirable, as for a longer existing resource there may be metrics or events that the user still wants to peek at before removing from inventory.

I think the above describes sort of "works as designed"

Note You need to log in before you can comment on or make changes to this bug.