[jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent failure of undeploy

[Dennis Reed (JIRA)]

    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617333#comment-12617333 ] 

Dennis Reed commented on JBDEPLOY-270:
--------------------------------------

Hot-deploy the attached descriptor several times in EAP 5.0.1 and you'll see it happen.

With logging added in org.jboss.beans.metadata.plugins.AbstractBeanMetaData#setName.
When deploying it may register:
    dennis$defaultEvictionRegionConfig#1
    dennis#2
    dennis$evictionConfig#3

Then while undeploying, unregister:
    dennis#1
    dennis$defaultEvictionRegionConfig#2
    dennis$evictionConfig#3

(leaving dennis$defaultEvictionRegionConfig#1 and dennis#2 registered)
So the next time it deploys, if it tries to register one of these, it gets the exception.

Doing some further testing in different versions, while it's simple to reproduce in EAP 5.0 and 5.0.1,
I'm unable to reproduce the exception in EAP 5.1 or 5.1.1.
(The components are still getting assigned different names during deploy and undeploy, but the 
"Unable to register deployment mbean" exception is not being thrown).

Was there a related change made in EAP 5.1?

> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira