Description of problem:

When redeploying via :deploy an application previously undeployed via :undeploy, the deployment is deployed, then undeployed, then deployed again. 

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

EAP 6.3.0.ER2

How reproducible:

always

Steps to Reproduce:
1. unzip jboss-eap-6.3.0.ER2.zip
2. cp tiny-webapp.war jboss-eap-6.3/standalone/deployments/ # tiny-webapp.war is a trivial single-JSP webapp, use whatever you have at hand
3. ./jboss-eap-6.3/bin/standalone.sh
4. ./jboss-eap-6.3/bin/jboss-cli.sh -c
5. /deployment=tiny-webapp.war:undeploy # then wait a few seconds
6. /deployment=tiny-webapp.war:deploy

Actual results:

(log of the :deploy operation on 6.3.0.ER2)

08:17:06,758 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "tiny-webapp.war" (runtime-name: "tiny-webapp.war")
08:17:06,790 INFO  [org.jboss.web] (ServerService Thread Pool -- 64) JBAS018210: Register web context: /tiny-webapp
08:17:06,891 INFO  [org.jboss.as.server] (management-handler-thread - 4) JBAS018559: Deployed "tiny-webapp.war" (runtime-name : "tiny-webapp.war")
08:17:09,491 INFO  [org.jboss.web] (ServerService Thread Pool -- 64) JBAS018224: Unregister web context: /tiny-webapp
08:17:09,499 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment tiny-webapp.war (runtime-name: tiny-webapp.war) in 10ms
08:17:09,501 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "tiny-webapp.war" (runtime-name: "tiny-webapp.war")
08:17:09,530 INFO  [org.jboss.web] (ServerService Thread Pool -- 65) JBAS018210: Register web context: /tiny-webapp
08:17:09,618 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "tiny-webapp.war" with deployment "tiny-webapp.war"

Expected results:

(log of the :deploy operation on 6.2.0.GA and 6.3.0.ER1 -- they are the same)

08:19:12,353 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "tiny-webapp.war" (runtime-name: "tiny-webapp.war")
08:19:12,378 INFO  [org.jboss.web] (ServerService Thread Pool -- 15) JBAS018210: Register web context: /tiny-webapp
08:19:12,464 INFO  [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "tiny-webapp.war" (runtime-name : "tiny-webapp.war")

Additional info:

I was able to track this down (via git bisect) to the commit e68c7615, which apparently is a fix of bug 1074999. This suggest a question if redeploying via :deploy is possibly a bad idea and :redeploy should be used instead. However:

1. This used to work before, and therefore would be considered API break.
2. Even if the previous behavior of :deploy was wrong and there is a genuine reason to change it, current behavior is wrong too. I will argue that noone wants a single :deploy operation to do the deployment _twice_.

Moreover, this affects clustering in a really bad way. I'm not able to reproduce it locally, but see this log: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-http-session-undeploy-repl-async/67/console-perf18/ where after :undeploy and then :deploy, the cluster doesn't form again:

10:59:26,010 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 77) ISPN000094: Received new cluster view: [perf18/web|0] [perf18/web]
10:59:26,010 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 77) ISPN000079: Cache local address is perf18/web, physical addresses are [172.17.81.254:55200]
10:59:26,011 ERROR [org.jboss.as.clustering] (MSC service thread 1-3) JBAS010223: ViewAccepted failed: java.lang.IllegalStateException: JBAS010240: Address perf18/web not registered in transport layer
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService$ClusterNodeFactoryImpl.getClusterNode(CoreGroupCommunicationService.java:1350) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService.translateAddresses(CoreGroupCommunicationService.java:1010) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService$GroupView.<init>(CoreGroupCommunicationService.java:1101) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService.processViewChange(CoreGroupCommunicationService.java:945) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService$MembershipListenerImpl.viewAccepted(CoreGroupCommunicationService.java:1403) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService.start(CoreGroupCommunicationService.java:793) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.as.clustering.impl.CoreGroupCommunicationService.start(CoreGroupCommunicationService.java:158) [jboss-as-clustering-impl-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]

(The same happens for perf18/ejb, of course.)

I'm not exactly sure why the deployer's weird behavior should affect clustering that badly, but it happens regularly and reverting the commit e68c7615 fixes the problem. Hence CCing Paul and Rado -- if you guys want me to open another BZ for clustering, please speak up.