Bug 1280262 - [GSS](6.4.z) replace-deployment command not working as expected in domain mode
[GSS](6.4.z) replace-deployment command not working as expected in domain mode
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: CR1
: EAP 6.4.12
Assigned To: Chao Wang
Martin Simka
: Reopened
Depends On:
Blocks: eap6412-payload
  Show dependency treegraph
Reported: 2015-11-11 06:06 EST by Abhijit humbe
Modified: 2017-12-06 22:07 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-06 21:37:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFCORE-1226 Major Resolved undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler 2018-05-21 11:32 EDT

  None (edit)
Description Abhijit humbe 2015-11-11 06:06:21 EST
Description of problem:
replace-deployment command not working as expected in domain mode

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

How reproducible:

Steps to Reproduce:

1. Start EAP 6.4.4 in domain mode and deploy application using following CLI command:
[domain@localhost:9999 /] deploy /Applications/WebApp-1.war --server-groups=main-server-group --name=WebApp-1.war --runtime-name=WebApp-1.war
2. Deploy next version of application in "disabled" state with same "runtime-name"  
[domain@localhost:9999 /] deploy /Applications/WebApp-2.war --disabled --name=WebApp-2.war --runtime-name=WebApp-1.war 

3. Now use replace-deployment command to access latest version of application:
[domain@localhost:9999 /] /server-group=main-server-group:replace-deployment(name=WebApp-2.war,to-replace=WebApp-1.war)
its working fine,laest version of application is accessable.

4. Now try to undeploy old version of application
After undploying older version, we are not able to access(404) latest version of application(WebApp-2.war) as well.To access it we have to redeploy it. 
Same steps are working fine in Standalone mode.

Actual results:

Expected results:

Additional info:
Comment 1 Mustafa Musaji 2015-11-11 06:30:12 EST
Some additional notes.

I think although this makes sense to a degree the behaviour across domain/standalone is not consistent.

If you are doing a replacement of a deployment, then I presume that undeploying the old one doesn't make any sense as it's not deployed (as you replaced the deployment with another) in which case I'd expect whatever references to it to be undeployed (in this case the new application?). But then I'd expect the same behaviour on standalone instance.
Comment 2 Brian Stansberry 2015-11-11 09:46:33 EST
I'm changing the component on this, as the CLI component is for client side issues, including high level commands, and it looks like the high level commands (steps 1 and 2) worked fine. Any problem here looks to be server side, either a bug in the handling of the low level ops or if they are actually working as designed, some odd semantics baked into the design.
Comment 3 Brian Stansberry 2015-11-11 12:47:03 EST
The problem here is how org.jboss.as.server.deployment.DeploymentUndeployHandler works. It makes the MSC changes regardless of whether the deployment=WebApp-1.war resource's 'enabled' attribute was 'true'. The MSC services are based on the runtime-name value of 'WebApp-1.war', so the services for deployment=WebApp-2.war get stopped.

I expect this can be seen easily enough with standalone as well. Just create two deployments, deployment=WebApp-1.war and deployment=WebApp-2.war, both with their runtime-name attribute set to 'WebApp-1.war', but with the deployment=WebApp-1.war resource's 'enabled' attribute set to 'false'. And then from CLI


The app should undeploy.
Comment 6 Mike McCune 2016-03-28 18:24:40 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 8 Michael Cada 2016-11-05 06:33:25 EDT
Verified with EAP 6.4.12.CP.CR1
Comment 9 Petr Penicka 2017-01-17 08:09:54 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
Comment 10 Abhijit humbe 2017-12-06 00:24:01 EST
This issue reintroduced in EAP 6.4 CP17 release, so I am reopening this bug
Comment 12 Abhijit humbe 2017-12-06 21:37:07 EST
I have opened new BZ-1523011 for EAP 6.4 CP17 release. Closing this BZ.

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