5 Replies Latest reply: Sep 4, 2013 2:55 AM by Tang Yong RSS

Problem with Classloading Isolation in JBoss 7.0.1

gnu Newbie

Hi all,

 

I have created an (Java EE 6) EAR project with two WAR projects within my Eclipse Indigo. Each web module contains only one simple bean with the same name and the @Named annotation attached. Each web module has an empty beans.xml, too.

 

(Hot-)deploying this EAR to my local JBoss 7.0.1 default instance causes the following error indicating that the classloader isolation in JBoss 7 does not work correctly.

 

10:59:54,723 INFO  [org.jboss.weld] (MSC service thread 1-1) Processing CDI deployment: multimodule-ear.ear

10:59:54,785 INFO  [org.jboss.weld] (MSC service thread 1-7) Processing CDI deployment: multimodule-war2.war

10:59:54,785 INFO  [org.jboss.weld] (MSC service thread 1-10) Processing CDI deployment: multimodule-war1.war

10:59:54,801 INFO  [org.jboss.weld] (MSC service thread 1-9) Starting Services for CDI deployment: multimodule-ear.ear

10:59:54,864 INFO  [org.jboss.weld.Version] (MSC service thread 1-9) WELD-000900 1.1.2 (Final)

10:59:54,879 INFO  [org.jboss.weld] (MSC service thread 1-7) Starting weld service

10:59:56,192 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.unit."multimodule-ear.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."multimodule-ear.ear".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name demoBean resolves to beans [Managed Bean [class demo1.DemoBean] with qualifiers [@Any @Default @Named], Managed Bean [class demo2.DemoBean] with qualifiers [@Any @Default @Named]]

    at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)

    at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]

    at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name demoBean resolves to beans [Managed Bean [class demo1.DemoBean] with qualifiers [@Any @Default @Named], Managed Bean [class demo2.DemoBean] with qualifiers [@Any @Default @Named]]

    at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:456)

    at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:342)

    at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:404)

    at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)

    at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)

    ... 5 more

 

10:59:56,192 ERROR [org.jboss.as] (MSC service thread 1-12) JBoss AS 7.0.1.Final "Zap" started (with errors) in 19547ms - Started 155 of 256 services (40 services failed or missing dependencies, 61 services are passive or on-demand)

10:59:56,410 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployment of "multimodule-ear.ear" was rolled back with failure message {"Failed services" => {"jboss.deployment.unit.\"multimodule-ear.ear\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"multimodule-ear.ear\".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name demoBean resolves to beans [Managed Bean [class demo1.DemoBean] with qualifiers [@Any @Default @Named], Managed Bean [class demo2.DemoBean] with qualifiers [@Any @Default @Named]]"}}

10:59:56,442 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment multimodule-war2.war in 38ms

10:59:56,442 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) Stopped deployment multimodule-war1.war in 38ms

10:59:56,442 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Stopped deployment multimodule-ear.ear in 40ms

10:59:56,442 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 1) {"Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"Failed services" => {"jboss.deployment.unit.\"multimodule-ear.ear\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"multimodule-ear.ear\".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name demoBean resolves to beans [Managed Bean [class demo1.DemoBean] with qualifiers [@Any @Default @Named], Managed Bean [class demo2.DemoBean] with qualifiers [@Any @Default @Named]]"}}}}

 

 

As per the JBoss 7 specification the classloaders of war-modules should be isolated per default, and therefore the two beans should not be visible to each other at all. Can you tell me, why this error then occurs and how I can prevent from it?

 

Thanks for your reply in advance.

Gnu

 

The multi-module sample is attached as a ZIP

  • 1. Re: Problem with Classloading Isolation in JBoss 7.0.1
    Dejan Kitic Newbie

    I think you need to explicitly enable isolation, check here:

    https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7

     

     

    <subsystem xmlns="urn:jboss:domain:ee:1.0" >             
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
    </subsystem>

     

    By default this is set to false, which allows the sub-deployments to see classes belonging to other sub-deployments within the .ear.

    I belive you need to set it to true, in order to isolate subdeployments.

  • 2. Re: Problem with Classloading Isolation in JBoss 7.0.1
    gnu Newbie

    Hi Dejan,

     

    I did both (subsequently). I modified my standalone.xml as you have described above as well as I added a jboss-deployment-structure.xml file to the META-INF directory of the EAR module setting the ear-subdeployments-isolated setting to true. But none of them worked. I get the same error during the deployment of the EAR as already shown above.

     

    And in the documentation (see the link you provided to me) there is mentioned, that this setting shouldn't have any effect on the isolated classloaders of WARs:

     

    "The ear-subdeployments-isolated element value has no effect on the isolated classloader of the .war file(s). i.e. irrespective of whether this flag is set to true or false, the .war within a .ear will have a isolated classloader and other sub-deployments within that .ear will not be able to access classes from that .war. This is as per spec."

     

    Gnu

  • 3. Re: Problem with Classloading Isolation in JBoss 7.0.1
    Dejan Kitic Newbie

    That 's odd, I tried the same thing you did, and same happens, weld complains about ambigous bean name.

  • 4. Re: Problem with Classloading Isolation in JBoss 7.0.1
    Jochen Mueller Newbie

    Hi all!

     

    Sorry for appending to this post after such a long time but I have the same problem with JBoss 7.1.1 final.

     

    I have several web apps inside an EAR and each web app contains a "base.jar" file which contains some common backing beans that shall be used in each web app. On JBoss startup the following exception is thrown (which references to this thread - a hint that this will not be fixed?).

     

    WELD-001414 Bean name is ambiguous. Name baseBean resolves to beans [Managed Bean [class foo.example.BaseBean] with qualifiers [@Any @Default @Named], Managed Bean [class foo.example.BaseBean] with qualifiers [@Any @Default @Named]]"}} - See more at: https://community.jboss.org/thread/173458#sthash.PJkn4CP8.dpuf

     

    The status of the "Related Issue" https://issues.jboss.org/browse/AS7-2533 is "Resolved" but I can't see, if this issue is really fixed in any version or will not be fixed at all.

    Maybe I overlooked something?

     

    Or maybe a workaround is existing?

     

    Thanks!

  • 5. Re: Problem with Classloading Isolation in JBoss 7.0.1
    Tang Yong Newbie

    The issue has been fixed and you can try wildfly-8.0.0.Alpha4.