Bug 1280262

Summary:	[GSS](6.4.z) replace-deployment command not working as expected in domain mode
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Abhijit humbe <abhumbe>
Component:	Domain Management	Assignee:	Chao Wang <chaowan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Simka <msimka>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4.4	CC:	bmaxwell, brian.stansberry, cdewolf, chaowan, dandread, jboss-set, jtruhlar, mcada, mmusaji, ppalaga
Target Milestone:	CR1	Keywords:	Reopened
Target Release:	EAP 6.4.12
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	eap6412-proposed
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-07 02:37:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1375585

Description Abhijit humbe 2015-11-11 11:06:21 UTC

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
~~~
/server-group=main-server-group/deployment=WebApp-1.war:undeploy()
~~~
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 11:30:12 UTC

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 14:46:33 UTC

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 17:47:03 UTC

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

/deployment=WebApp-1.war:undeploy

The app should undeploy.

Comment 6 Mike McCune 2016-03-28 22:24:40 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 8 Michael Cada 2016-11-05 10:33:25 UTC

Verified with EAP 6.4.12.CP.CR1

Comment 9 Petr Penicka 2017-01-17 13:09:54 UTC

Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 10 Abhijit humbe 2017-12-06 05:24:01 UTC

This issue reintroduced in EAP 6.4 CP17 release, so I am reopening this bug

Comment 12 Abhijit humbe 2017-12-07 02:37:07 UTC

I have opened new BZ-1523011 for EAP 6.4 CP17 release. Closing this BZ.