Bug 824498 - Update farmed Application Deployment (EAR/WAR) results in non-farmed deployment
Update farmed Application Deployment (EAR/WAR) results in non-farmed deployment
Status: CLOSED DUPLICATE of bug 824502
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 5 (Show other bugs)
JON 3.1.0
All All
urgent Severity high
: ---
: JON 3.1.0
Assigned To: Stefan Negrea
Mike Foley
:
Depends On: 824151
Blocks: jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
 
Reported: 2012-05-23 11:33 EDT by Larry O'Leary
Modified: 2012-05-23 18:54 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: EMBJOPR-366
Environment:
JON 2.4 EAP 5.0.1 admin-console
Last Closed: 2012-05-23 11:45:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Larry O'Leary 2012-05-23 11:33:09 EDT
+++ This bug was initially created as a clone of upstream Bug #646631 +++

Description of problem:
If an application is deployed to an AS instance's farm directory and the Update Content operation is performed, application is no longer deployed to farm.

Version-Release number of selected component (if applicable):
RHQ 3.0.0
JON 2.4.0
Embedded JOPR (admin-console) with EAP 5.0.0, EAP 5.0.1

How reproducible:
Always

Steps to Reproduce:
1. Setup a two node EAP cluster
2. Deploy an application (EAR/WAR) to node1's farm using admin-console
3. Verify application was deployed to both node1 and node2
4. Update the application using the same EAR/WAR (From admin-console, expand and select the deployed EAR/WAR and select it's Content tab and then click Update)

  
Actual results:
The updated deployed application is now only deployed to node1 in its deploy directory

Expected results:
The updated deployed application is deployed to node1 and node2 and appears in their farm directory

Additional info:
This is a result of the StandaloneManagedDeploymentComponent.deployPackages method invoking DeploymentUtils.deployArchive without a means of passing in whether to deploy farmed or not. Currently, the method appears to support a deployExploded boolean but no method of passing in whether it is farmed or not. The DeploymentUtils.deployArchive method should probably accept a deployFarmed boolean as well as the deployPackages method being updated to check to see if the updated deployment was farmed. Of course, this may be very error prone as this would be directly tied to a hard-coded path name. Maybe we should gather these options from ProfileService or Inventory before we remove the old deployment?
Comment 1 Larry O'Leary 2012-05-23 11:45:20 EDT

*** This bug has been marked as a duplicate of bug 824502 ***

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