Red Hat Bugzilla – Bug 1280262
[GSS](6.4.z) replace-deployment command not working as expected in domain mode
Last modified: 2017-12-06 22:07:36 EST
Description of problem:
replace-deployment command not working as expected in domain mode
Version-Release number of selected component (if applicable):
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.
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.
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.
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.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see firstname.lastname@example.org with any questions
Verified with EAP 6.4.12.CP.CR1
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
This issue reintroduced in EAP 6.4 CP17 release, so I am reopening this bug
I have opened new BZ-1523011 for EAP 6.4 CP17 release. Closing this BZ.