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:
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.
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.
Forked new bug for discovered issue: https://bugzilla.redhat.com/show_bug.cgi?id=749804
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.
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.
~/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.
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)
Created attachment 532812 [details] Missing Filename and Context, EVERYWHERE!
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.
Created attachment 532842 [details] After Selecting Currently Subscribed Repository Get NULL Error
Created attachment 532843 [details] After Selecting Existing Repository Get Seam Page (Ick!)
Created attachment 532844 [details] Undefined Repository Values
Created attachment 532845 [details] Seam Page that Came Up After "Existing" Selected
(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.
(like i said, lets get JIRA) typo again... that's bugs 7 and 8, not 8 and 9.
Created attachment 533161 [details] After WAR
Created attachment 533162 [details] Before WAR
Created attachment 533163 [details] Bundle
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.
Closing due to inactivity, assuming better in current release.