Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Updating an EAR/WAR originally deployed to non-default location deploys to [different] default location|
|Product:||[Other] RHQ Project||Reporter:||dsteigne|
|Component:||Plugins||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||3.0.0||CC:||jshaughn, rbuck, rsoares|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||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:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||752918, 752919, 752920, 752921, 752925, 752926, 752928, 752929, 753761, 745494, 749804, 752761|
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 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.