Bug 672240

Summary: Updating an EAR/WAR originally deployed to non-default location deploys to [different] default location
Product: [Other] RHQ Project Reporter: dsteigne
Component: PluginsAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.0.0CC: jshaughn, rbuck, rsoares
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
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 19:17:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 752918, 752919, 752920, 752921, 752925, 752926, 752928, 752929, 753761, 745494, 749804, 752761    
Attachments:
Description Flags
Missing Filename and Context, EVERYWHERE!
none
After Selecting Currently Subscribed Repository Get NULL Error
none
After Selecting Existing Repository Get Seam Page (Ick!)
none
Undefined Repository Values
none
Seam Page that Came Up After "Existing" Selected
none
After WAR
none
Before WAR
none
Bundle none

Description dsteigne 2011-01-24 15:03:42 UTC
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 15:39:06 UTC
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 20:11:26 UTC
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 13:39:56 UTC
Forked new bug for discovered issue:
   https://bugzilla.redhat.com/show_bug.cgi?id=749804

Comment 4 Robert Buck 2011-11-07 12:33:31 UTC
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 12:39:23 UTC
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 12:46:23 UTC
~/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 12:10:35 UTC
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 12:13:52 UTC
Created attachment 532812 [details]
Missing Filename and Context, EVERYWHERE!

Comment 9 Robert Buck 2011-11-10 13:38:52 UTC
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 13:39:51 UTC
Created attachment 532842 [details]
After Selecting Currently Subscribed Repository Get NULL Error

Comment 11 Robert Buck 2011-11-10 13:40:35 UTC
Created attachment 532843 [details]
After Selecting Existing Repository Get Seam Page (Ick!)

Comment 12 Robert Buck 2011-11-10 13:41:20 UTC
Created attachment 532844 [details]
Undefined Repository Values

Comment 13 Robert Buck 2011-11-10 13:42:01 UTC
Created attachment 532845 [details]
Seam Page that Came Up After "Existing" Selected

Comment 14 Robert Buck 2011-11-10 13:50:15 UTC
(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 13:51:16 UTC
(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 20:35:14 UTC
Created attachment 533161 [details]
After WAR

Comment 17 Robert Buck 2011-11-11 20:35:38 UTC
Created attachment 533162 [details]
Before WAR

Comment 18 Robert Buck 2011-11-11 20:36:00 UTC
Created attachment 533163 [details]
Bundle

Comment 19 Robert Buck 2011-11-14 13:58:01 UTC
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 19:17:50 UTC
Closing due to inactivity, assuming better in current release.