[JBoss JIRA] Created: (JBAS-4379) MC beans deployed twice because of jacc service
by Thomas Diesler (JIRA)
MC beans deployed twice because of jacc service
-----------------------------------------------
Key: JBAS-4379
URL: http://jira.jboss.com/jira/browse/JBAS-4379
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.CR1
The latest jboss.sar contains MC bean definitions as well as a war
[tdiesler@tddell build]$ jar -tf ../integration-jboss50/output/lib/jbossws50.sar | sort
jbossws-context.war
jbossws-core.jar
META-INF/
META-INF/jbossws-beans.xml
META-INF/MANIFEST.MF
META-INF/standard-jaxrpc-client-config.xml
META-INF/standard-jaxrpc-endpoint-config.xml
META-INF/standard-jaxws-client-config.xml
META-INF/standard-jaxws-endpoint-config.xml
policy.jar
wsdl4j.jar
xmlsec.jar
It seams that because of the JACC service the bean definitions are deployed twice
12:55:04,409 ERROR [BeanMetaDataDeployer] Error during deployment: jboss:id=jbossws.sar,service=jacc
org.jboss.deployers.spi.DeploymentException: Error deploying: KernelLocator
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:71)
at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:56)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:603)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:603)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBMICROCONT-159) Multiple components
by Scott M Stark (JIRA)
Multiple components
--------------------
Key: JBMICROCONT-159
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-159
Project: JBoss MicroContainer
Issue Type: Bug
Components: Deployment
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
There is a problem with how component deployments are handled. When a DeploymentUnit contains multiple sources of component metadata (a jar with a META-INF/*-beans.xml,*-service.xml for example), duplicate processing of components is occuring. This is due to the AbstractComponentDeployer.deployComponents query for the component metadata:
protected void deployComponents(DeploymentUnit unit) throws DeploymentException
{
if (compVisitor == null)
return;
Set<? extends C> components = unit.getAllMetaData(componentType);
for (C component : components)
compVisitor.deploy(unit, component);
}
The DeploymentUnit.getAllMetaData(componentType) for the current DeploymentComponentContext looks to its parent for metadata. This combined with the recursive processing in the MainDeployerImpl.commitDeploy:
private void commitDeploy(Deployer deployer, DeploymentContext context, Set<DeploymentContext> components)
throws DeploymentException
{
DeploymentContext[] theComponents = null;
if (components != null && components.isEmpty() == false)
theComponents = components.toArray(new DeploymentContext[components.size()]);
DeploymentUnit unit = context.getDeploymentUnit();
deployer.commitDeploy(unit);
try
{
if (theComponents != null)
{
for (int i = 0; i < theComponents.length; ++i)
{
try
{
Set<DeploymentContext> componentComponents = theComponents[i].getComponents();
commitDeploy(deployer, theComponents[i], componentComponents);
}
catch (DeploymentException e)
{
// Unwind the previous components
for (int j = i-1; j >=0; --j)
prepareUndeploy(deployer, theComponents[j], true);
throw e;
}
}
}
}
catch (DeploymentException e)
{
prepareUndeploy(deployer, context, false);
throw e;
}
}
Results in a structure like:
DU(some.jar)
+ CDC(Bean1)
+ CDC(ServiceBean2)
+ CDC(Bean2)
+ CDC(ServiceBean2)
+ CDC(ServiceBean1)
+ CDC(ServiceBean2)
+ CDC(ServiceBean2)
The service deployer components are being recursively added to the kernel components and duplicate install errors result.
See the org.jboss.test.deployers.deployer.test.MultipleComponentTypeUnitTestCase
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBCACHE-707) PojoCache to aspectize JDom classes
by Ben Wang (JIRA)
PojoCache to aspectize JDom classes
-----------------------------------
Key: JBCACHE-707
URL: http://jira.jboss.com/jira/browse/JBCACHE-707
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: POJOCache
This is suggested by Bela during a customer visit. Idea is the customer is using JDom internally to store the documents such as mail, fax, email, parcel, and the like. However, for clustering purpose, each single update on document element would require replication of the whole document. Not a very efficient process.
If PojoCache can aspectize JDom classes then fine-grained replication can be done transparently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months