Bug 672240 - Updating an EAR/WAR originally deployed to non-default location deploys to [different] default location
Updating an EAR/WAR originally deployed to non-default location deploys to [d...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
3.0.0
All All
unspecified Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks: 752918 752919 752920 752921 752925 752926 752928 752929 753761 jon30-sprint8 749804 752761
  Show dependency treegraph
 
Reported: 2011-01-24 10:03 EST by dsteigne
Modified: 2014-07-03 15:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 749804 752761 752918 752919 752920 752921 752925 752926 752928 753761 (view as bug list)
Environment:
Last Closed: 2014-07-03 15:17:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Missing Filename and Context, EVERYWHERE! (189.96 KB, image/png)
2011-11-10 07:13 EST, Robert Buck
no flags Details
After Selecting Currently Subscribed Repository Get NULL Error (196.25 KB, image/png)
2011-11-10 08:39 EST, Robert Buck
no flags Details
After Selecting Existing Repository Get Seam Page (Ick!) (238.11 KB, image/png)
2011-11-10 08:40 EST, Robert Buck
no flags Details
Undefined Repository Values (194.24 KB, image/png)
2011-11-10 08:41 EST, Robert Buck
no flags Details
Seam Page that Came Up After "Existing" Selected (104.42 KB, application/xhtml+xml)
2011-11-10 08:42 EST, Robert Buck
no flags Details
After WAR (1.16 KB, application/x-webarchive)
2011-11-11 15:35 EST, Robert Buck
no flags Details
Before WAR (1003 bytes, application/x-webarchive)
2011-11-11 15:35 EST, Robert Buck
no flags Details
Bundle (1.31 KB, application/zip)
2011-11-11 15:36 EST, Robert Buck
no flags Details

  None (edit)
Description dsteigne 2011-01-24 10:03:42 EST
Description of problem:
When you try to update an existent EAR/WAR vi JON (JBossAS -> Resource child (EAR/WAR) -> CONTENT -> New -> upload a new version)... If the resource resides in a different dir than the default (deploy) the agent removes the original file and deploy the new version (uploaded) inside JBOSS_HOME/server/<profile>/deploy/.

This also occurs if you try to update a resource inside the farm deploy dir. This is worse because when the agent removes a file from farm dir the Farm Service removes the file from all cluster nodes. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Robert Buck 2011-10-27 11:39:06 EDT
The key point here that was not clear to me when I first read this report was that the updated module ends up in a different location than originally deployed to.
Comment 2 Robert Buck 2011-10-27 16:11:26 EDT
I am not seeing quite the same thing, 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.
Comment 3 Robert Buck 2011-10-28 09:39:56 EDT
Forked new bug for discovered issue:
   https://bugzilla.redhat.com/show_bug.cgi?id=749804
Comment 4 Robert Buck 2011-11-07 07:33:31 EST
I don't see the original problem, I see LOTS of other problems though. One...

1. When it deployed the new war it wiped out the original location then complained that it did not find what it just deleted:

Could not find application to update at location: /home/rbuck/dev/servers/jboss-eap/5.1.0/jboss-as/server/n01/deploy/helloworlt/helloworld.war

2. The manifest version number is not getting picked up properly, it seems to default to 1.0 even if I manually set it to 2.0.
Comment 5 Robert Buck 2011-11-07 07:39:23 EST
Worse yet, if I remove the hello world directory entirely from JBoss it does not undeploy it; I can still refresh the HelloWorld.jsp page associated to it. The application still exists in the work directory.
Comment 6 Robert Buck 2011-11-07 07:46:23 EST
~/dev/servers/jboss-eap/5.1.0/jboss-as/server$ find . -type d -name "hello*"

./n02/deploy/helloworlt
./n02/tmp/3j011-iciuou-gupeukge-1-gupffzep-du/helloworld.war
./n02/work/jboss.web/localhost/helloworld

But it all still runs on 8080, that's instance n01.

When I remove all traces of the deployments from all locations, it still appears JBoss still has retained it in memory.
Comment 7 Robert Buck 2011-11-10 07:10:35 EST
Initial Steps for all Related Bugs Below:

Create Child
 Type: WAR
 Version: 7
Upload WAR
Deploy Farmed
 Timeout: 30 s
Finish
F5 Refresh Browser
Navigate: n01/Applications/Web Applications/helloworld.war

BUG 1. Unsupported Operation Exception Bug:

a. Content/Delete selected

BUG 2. Grayed Out Tabs Bug:

a. Inventory Tab
b. Click on resource, navigating to child resource
c. Select Inventory tab (all tabs become disabled)

BUG 3. Uninventory Bug:

From Inventory tab, once helloworld.war is uninventoried, I cannot reinventory.

BUG 4. Global Exception Under Inventory Connection Settings

a. Select Connection Settings (POOF!!!) - fields are empty as they are for EVERY resource!!!!

BUG 5. Update goes to Wrong Location

a. Content tab
b. Upload new WAR
c. Select farm repository
d. Finish

Also, on a fresh database it appears as though a fresh install has no record of farm path, so farm is not an option for BUG 5 step c. This tends to imply the database model is not right; old state is being used, but when the old state doesnt exist on a new database, no option exists for the default repository. Ideally, if it detects a repository, it should set it as the default, not None which ALWAYS moves it.

BUG 6: Delete as Child Resource of n01 Succeeds by removing it from RHQ database but fails to remove it from JBoss, and I cannot uninventory.

a. Go to parent resource, n01
b. Inventory/Child Resources
c. Highlight helloworld app
d. Press Delete button (no error, says succeeded, but checking jboss says otherwise, must delete from jboss directly instead of from RHQ)
Comment 8 Robert Buck 2011-11-10 07:13:52 EST
Created attachment 532812 [details]
Missing Filename and Context, EVERYWHERE!
Comment 9 Robert Buck 2011-11-10 08:38:52 EST
Content
New
Upload New Package

Bug 7 - JBoss Seam Page shows up when failure occurs
Select Existing (even though it is clearly screwed up)
Poof - you will see an embedded JBoss Seam page nested within our Child Inventory page

Bug 8 - Data Corruption
Notice the Currently Subscribed Repository is not just empty, but undefined!!!
See png image
Yeilds, "Failed to create package [helloworld.war] in repository. Cause: java.lang.NumberFormatException:null ".
Now, this only occurs IFF you have a brand new clean database. This is likely a data corruption or inconsistency problem; it tends to imply that later invocations use prior state as the Repository, potentially moving WAR files from their intended locations.
Comment 10 Robert Buck 2011-11-10 08:39:51 EST
Created attachment 532842 [details]
After Selecting Currently Subscribed Repository Get NULL Error
Comment 11 Robert Buck 2011-11-10 08:40:35 EST
Created attachment 532843 [details]
After Selecting Existing Repository Get Seam Page (Ick!)
Comment 12 Robert Buck 2011-11-10 08:41:20 EST
Created attachment 532844 [details]
Undefined Repository Values
Comment 13 Robert Buck 2011-11-10 08:42:01 EST
Created attachment 532845 [details]
Seam Page that Came Up After "Existing" Selected
Comment 14 Robert Buck 2011-11-10 08:50:15 EST
(In reply to comment #9)
> Content
> New
> Upload New Package
> 
> Bug 7 - JBoss Seam Page shows up when failure occurs
> Select Existing (even though it is clearly screwed up)
> Poof - you will see an embedded JBoss Seam page nested within our Child
> Inventory page
> 
> Bug 8 - Data Corruption
> Notice the Currently Subscribed Repository is not just empty, but undefined!!!
> See png image
> Yeilds, "Failed to create package [helloworld.war] in repository. Cause:
> java.lang.NumberFormatException:null ".
> Now, this only occurs IFF you have a brand new clean database. This is likely a
> data corruption or inconsistency problem; it tends to imply that later
> invocations use prior state as the Repository, potentially moving WAR files
> from their intended locations.

(wish this were JIRA where editing is permitted)

Regarding bugs 8 and 9, the first three lines are initial steps for BOTH.
Comment 15 Robert Buck 2011-11-10 08:51:16 EST
(like i said, lets get JIRA)

typo again... that's bugs 7 and 8, not 8 and 9.
Comment 16 Robert Buck 2011-11-11 15:35:14 EST
Created attachment 533161 [details]
After WAR
Comment 17 Robert Buck 2011-11-11 15:35:38 EST
Created attachment 533162 [details]
Before WAR
Comment 18 Robert Buck 2011-11-11 15:36:00 EST
Created attachment 533163 [details]
Bundle
Comment 19 Robert Buck 2011-11-14 08:58:01 EST
One thing I observe for this particular bug is that a deployed helloworld war is missing nearly all the truly important information in the database; the context and path are undefined, whereas for anything discovered inside JBoss they all have these fields defined.
Comment 20 Jay Shaughnessy 2014-07-03 15:17:50 EDT
Closing due to inactivity, assuming better in current release.

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