[jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent failure of undeploy
[
https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plug...
]
Ales Justin commented on JBDEPLOY-270:
--------------------------------------
OK, I see what the real problem is.
It's how AbstractBeanMetaData handles NestedBeanHandler.
It goes and re-creates a new nested bean list on every getBean invocation.
Where MetaDataVisitorNode uses set to order metadata children, hence PropertyMetaData is
randomly ordered --> diff counter number.
Caching AbstractBeanMetaData::getBeans would probably fix this problem.
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