glassfish
  1. glassfish
  2. GLASSFISH-20793

GF4 deployment error when having two web projects under one ear with equal managed bean names

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b89_RC5
    • Fix Version/s: None
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Win 7 Pro 64Bit
      GlassFish Server Open Source Edition 4.0 (build 89)
      GlassFish 4.0.1 b04 09/03/2013
      jdk1.7.0_21

      Description

      We are currently evaluating glassfish 4 for migration of our enterprise projects from glassfish 3.1.2.2. One problem we noticed is that now deployment fails with an ambiguity error message when having two web projects under one ear with equal managed bean names (see stacktrace below). In this case we created two simple jsf web projects contained in the same ear. Both wars contain a managed bean with same managed bean names ('greetingBean'). On GF3.x it works without problems.

      @Named
      @RequestScoped
      public class GreetingBean {

      public String getGreeting()

      { return "Hello from " + getClass().getName(); }

      }

      -------
      org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
      at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225)
      at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
      at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
      at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
      at java.security.AccessController.doPrivileged(Native Method)
      at javax.security.auth.Subject.doAs(Subject.java:356)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
      at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
      at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
      at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
      at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
      at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
      at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
      at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
      at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
      at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
      at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
      at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
      at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
      at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
      at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
      at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
      at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
      at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
      at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
      at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
      at java.lang.Thread.run(Thread.java:722)
      Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414 Bean name is ambiguous. Name greetingBean resolves to beans [Managed Bean [class test.web2.GreetingBean] with qualifiers [@Default @Any @Named], Managed Bean [class test.web1.GreetingBean] with qualifiers [@Default @Any @Named]]
      at org.jboss.weld.bootstrap.Validator.validateBeanNames(Validator.java:639)
      at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:488)
      at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:536)
      at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:216)
      ... 36 more
      -------

        Activity

        Hide
        TangYong added a comment -

        Component/s should be CDI.

        Show
        TangYong added a comment - Component/s should be CDI.
        Hide
        Manfred Riem added a comment -

        Reassigning to JJ as this looks like a CDI specific issue.

        Show
        Manfred Riem added a comment - Reassigning to JJ as this looks like a CDI specific issue.
        Hide
        TangYong added a comment -

        Change Component/s into CDI

        Show
        TangYong added a comment - Change Component/s into CDI
        Hide
        TangYong added a comment - - edited

        I did a demo(attachment) to re-produce the issue.

        PL. JJ confirms it.

        Notice that the following,

        1. Bean in different wars should be allowed to have the same EL name
        https://issues.jboss.org/browse/CDI-188

        2. Ambiguous name validation should not cross visibility boundaries
        https://issues.jboss.org/browse/WELD-1065

        From JBOSS Team's reply,
        "
        It is not portable to have multiple classes of the same name within the deployment. Weld currently does not support this..."

        It seems that this issue is not still planned to be fix.

        Thanks
        Tang

        Show
        TangYong added a comment - - edited I did a demo(attachment) to re-produce the issue. PL. JJ confirms it. Notice that the following, 1. Bean in different wars should be allowed to have the same EL name https://issues.jboss.org/browse/CDI-188 2. Ambiguous name validation should not cross visibility boundaries https://issues.jboss.org/browse/WELD-1065 From JBOSS Team's reply, " It is not portable to have multiple classes of the same name within the deployment. Weld currently does not support this..." It seems that this issue is not still planned to be fix. Thanks Tang
        Hide
        TangYong added a comment -

        New Confirmation is as following:

        1. The issue can be re-produced using GlassFish 4.0.1 b04 09/03/2013

        http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/nightly/latest-glassfish.zip (b04 09/03/2013)

        2. The issue does not happen using wildfly-8.0.0.Alpha4
        "
        15:01:23,451 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-ear.ear
        15:01:23,498 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.1.Final
        15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment eartwowars-war1-1.0.0.war
        15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-war2-1.0.0.war
        15:01:23,607 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: eartwowars-ear.ear
        15:01:23,638 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.3 (Final)
        15:01:23,732 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment eartwowars-ear.ear
        15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018210: Register web context: /eartwowars-war1
        15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS018210: Register web context: /eartwowars-war2
        15:01:24,670 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "eartwowars-ear.ear" (runtime-name : "eartwowars-ear.ear")"

        3. GlassFish 4.0.1 b04 and wildfly-8.0.0.Alpha4 all uses weld-osgi-bundle 2.0.3.Final.

        So, I can make an initial conclusion that maybe the issue is caused by GlassFish Weld Integration and I raised up Priority of the issue.

        Show
        TangYong added a comment - New Confirmation is as following: 1. The issue can be re-produced using GlassFish 4.0.1 b04 09/03/2013 http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/nightly/latest-glassfish.zip (b04 09/03/2013) 2. The issue does not happen using wildfly-8.0.0.Alpha4 " 15:01:23,451 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-ear.ear 15:01:23,498 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-1) HV000001: Hibernate Validator 5.0.1.Final 15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment eartwowars-war1-1.0.0.war 15:01:23,576 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment eartwowars-war2-1.0.0.war 15:01:23,607 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016005: Starting Services for CDI deployment: eartwowars-ear.ear 15:01:23,638 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900 2.0.3 (Final) 15:01:23,732 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment eartwowars-ear.ear 15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018210: Register web context: /eartwowars-war1 15:01:24,513 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS018210: Register web context: /eartwowars-war2 15:01:24,670 INFO [org.jboss.as.server] (XNIO-1 task-3) JBAS018559: Deployed "eartwowars-ear.ear" (runtime-name : "eartwowars-ear.ear")" 3. GlassFish 4.0.1 b04 and wildfly-8.0.0.Alpha4 all uses weld-osgi-bundle 2.0.3.Final. So, I can make an initial conclusion that maybe the issue is caused by GlassFish Weld Integration and I raised up Priority of the issue.
        Hide
        replicant77 added a comment - - edited

        Interesting to notice is that switching from cdi to jsf managed bean declarations resolves the issue. As we reference these beans in jsf pages, this is a better workaround for us than renaming the bean names.

        @javax.faces.bean.ManagedBean
        @javax.faces.bean.RequestScoped
        //@javax.inject.Named
        //@javax.enterprise.context.RequestScoped
        public class GreetingBean {

        public String getGreeting()

        { return "Hello from " + getClass().getName(); }

        }

        Show
        replicant77 added a comment - - edited Interesting to notice is that switching from cdi to jsf managed bean declarations resolves the issue. As we reference these beans in jsf pages, this is a better workaround for us than renaming the bean names. @javax.faces.bean.ManagedBean @javax.faces.bean.RequestScoped //@javax.inject.Named //@javax.enterprise.context.RequestScoped public class GreetingBean { public String getGreeting() { return "Hello from " + getClass().getName(); } }
        Hide
        TangYong added a comment -

        Java EE 7(or Higher) recommended using backing bean(using CDI concept) with JSF rather than ManagedBean. The ManagedBean has been outdated and although the workaround is valid for your current issue, It is hard to say that in the future, once GlassFish does not support ManagedBean, whether you will come back the scene again.

        Backing to the issue, I am investigating it and this should belong to Bean visibility problem while building BDAs.

        Thanks
        Tang

        Show
        TangYong added a comment - Java EE 7(or Higher) recommended using backing bean(using CDI concept) with JSF rather than ManagedBean. The ManagedBean has been outdated and although the workaround is valid for your current issue, It is hard to say that in the future, once GlassFish does not support ManagedBean, whether you will come back the scene again. Backing to the issue, I am investigating it and this should belong to Bean visibility problem while building BDAs. Thanks Tang
        Hide
        TangYong added a comment -

        JJ

        The reason for the issue has been found as following,

        For an ear with two wars, while deploying the ear, GlassFish Weld Integration created several Bean Managers corresponding to different BDAs. Among them, there is a Bean Manager liking AppBda_XXX-YYY which corresponds to the EAR BDA, and there are also two Bean Managers which correspond to the wars. The important point is that the EAR's Bean Manager's getAccessibleManagers() contains the wars's Bean Managers.

        Then, while org.jboss.weld.bootstrap.Validator calls the following,

        public void validateBeanNames(BeanManagerImpl beanManager) {
        ...
        for (Bean<?> bean : beanManager.getAccessibleBeans())

        { ... }

        getAccessibleBeans() will call org.jboss.weld.manager.BeanManagers.buildAccessibleClosure(...),

        The buildAccessibleClosure(...) will obtain all contained Bean Managers related to current Bean Manager by using getAccessibleManagers().

        So, war1 and war2's beans with the same name will be added Validator's "namedAccessibleBeans" as following,

        for (Bean<?> bean : beanManager.getAccessibleBeans()) {
        if (bean.getName() != null)

        { namedAccessibleBeans.put(bean.getName(), bean); }

        }

        And the exception happened.

        Deeply, the issue should be related to Bean Manager's visibility. I think that we should not make war1 and war2's Bean Manager visible to EAR's Bean Manager.

        Thanks
        Tang

        Show
        TangYong added a comment - JJ The reason for the issue has been found as following, For an ear with two wars, while deploying the ear, GlassFish Weld Integration created several Bean Managers corresponding to different BDAs. Among them, there is a Bean Manager liking AppBda_XXX-YYY which corresponds to the EAR BDA, and there are also two Bean Managers which correspond to the wars. The important point is that the EAR's Bean Manager's getAccessibleManagers() contains the wars's Bean Managers. Then, while org.jboss.weld.bootstrap.Validator calls the following, public void validateBeanNames(BeanManagerImpl beanManager) { ... for (Bean<?> bean : beanManager.getAccessibleBeans()) { ... } getAccessibleBeans() will call org.jboss.weld.manager.BeanManagers.buildAccessibleClosure(...), The buildAccessibleClosure(...) will obtain all contained Bean Managers related to current Bean Manager by using getAccessibleManagers(). So, war1 and war2's beans with the same name will be added Validator's "namedAccessibleBeans" as following, for (Bean<?> bean : beanManager.getAccessibleBeans()) { if (bean.getName() != null) { namedAccessibleBeans.put(bean.getName(), bean); } } And the exception happened. Deeply, the issue should be related to Bean Manager's visibility. I think that we should not make war1 and war2's Bean Manager visible to EAR's Bean Manager. Thanks Tang
        Hide
        jjsnyder83 added a comment -

        I also spoke with the JBoss guys and this should be valid. I will look at it shortly.

        Show
        jjsnyder83 added a comment - I also spoke with the JBoss guys and this should be valid. I will look at it shortly.
        Hide
        TangYong added a comment -

        JJ

        Fixing place has been confirmed as following,

        Class: org.glassfish.weld.DeploymentImpl
        Method: addAppBda()
        Place to need to fix:
        private void addAppBda() {
        ...
        // make all bdas visible to the app Bda. But none have visibility to App Bda
        for ( BeanDeploymentArchive oneBda : beanDeploymentArchives ) {
        if ( ! oneBda.equals(appBda))

        { appBda.getBeanDeploymentArchives().add(oneBda); }

        }
        }

        Whether can remove the above logic and make appBda not contain any child bda?

        Thanks
        Tang

        Show
        TangYong added a comment - JJ Fixing place has been confirmed as following, Class: org.glassfish.weld.DeploymentImpl Method: addAppBda() Place to need to fix: private void addAppBda() { ... // make all bdas visible to the app Bda. But none have visibility to App Bda for ( BeanDeploymentArchive oneBda : beanDeploymentArchives ) { if ( ! oneBda.equals(appBda)) { appBda.getBeanDeploymentArchives().add(oneBda); } } } Whether can remove the above logic and make appBda not contain any child bda? Thanks Tang
        Hide
        TangYong added a comment -

        I have made an fixing by removing the above logic, then , replaced the weld-integration bundle using self-built version on 4.0.1-b02. While deploying demo(attachment),

        E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\bin>asadmin deploy E:\NanjingJUG\GLASSFISH-20793\ear\target\eartwowars-ear.ear
        Application deployed with name eartwowars-ear.
        Command deploy executed successfully.

        [server.log]
        ...
        [2013-09-05T11:19:31.304+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571304] [levelValue: 800] [[
        Loading application eartwowars-ear#eartwowars-war1-1.0.0.war at [/eartwowars-war1]]]

        [2013-09-05T11:19:31.336+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571336] [levelValue: 800] [[
        Loading application eartwowars-ear#eartwowars-war2-1.0.0.war at [/eartwowars-war2]]]

        [2013-09-05T11:19:31.398+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571398] [levelValue: 800] [[
        eartwowars-ear was successfully deployed in 4,171 milliseconds.]]

        Pl. confirming the fix.

        Thanks
        Tang

        Show
        TangYong added a comment - I have made an fixing by removing the above logic, then , replaced the weld-integration bundle using self-built version on 4.0.1-b02. While deploying demo(attachment), E:\NanjingJUG\glassfish-4.0.1-b02\glassfish4\glassfish\bin>asadmin deploy E:\NanjingJUG\ GLASSFISH-20793 \ear\target\eartwowars-ear.ear Application deployed with name eartwowars-ear. Command deploy executed successfully. [server.log] ... [2013-09-05T11:19:31.304+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571304] [levelValue: 800] [[ Loading application eartwowars-ear#eartwowars-war1-1.0.0.war at [/eartwowars-war1] ]] [2013-09-05T11:19:31.336+0900] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571336] [levelValue: 800] [[ Loading application eartwowars-ear#eartwowars-war2-1.0.0.war at [/eartwowars-war2] ]] [2013-09-05T11:19:31.398+0900] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=41 _ThreadName=admin-listener(2)] [timeMillis: 1378347571398] [levelValue: 800] [[ eartwowars-ear was successfully deployed in 4,171 milliseconds.]] Pl. confirming the fix. Thanks Tang
        Hide
        jjsnyder83 added a comment -

        I have been looking into the issue and tried the same change but it causes a tck failure. I have to remove the app bda completely and at the same time provide a fix for the tck failure. I should have something soon.

        Show
        jjsnyder83 added a comment - I have been looking into the issue and tried the same change but it causes a tck failure. I have to remove the app bda completely and at the same time provide a fix for the tck failure. I should have something soon.
        Hide
        jjsnyder83 added a comment -

        Ok, I have a fix that I will submit tomorrow.

        Show
        jjsnyder83 added a comment - Ok, I have a fix that I will submit tomorrow.
        Hide
        jjsnyder83 added a comment -

        Committed revision 62703

        Show
        jjsnyder83 added a comment - Committed revision 62703

          People

          • Assignee:
            jjsnyder83
            Reporter:
            replicant77
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: