[GLASSFISH-20793] GF4 deployment error when having two web projects under one ear with equal managed bean names Created: 03/Sep/13  Updated: 06/Sep/13  Resolved: 06/Sep/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: replicant77 Assignee: jjsnyder83
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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


Attachments: Zip Archive GLASSFISH-20793_demo.zip    
Tags: cdi, glassfish4, jsf, weld

 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
-------



 Comments   
Comment by TangYong [ 03/Sep/13 ]

Component/s should be CDI.

Comment by Manfred Riem [ 03/Sep/13 ]

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

Comment by TangYong [ 03/Sep/13 ]

Change Component/s into CDI

Comment by TangYong [ 04/Sep/13 ]

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

Comment by TangYong [ 04/Sep/13 ]

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.

Comment by replicant77 [ 04/Sep/13 ]

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(); }

}

Comment by TangYong [ 04/Sep/13 ]

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

Comment by TangYong [ 04/Sep/13 ]

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

Comment by jjsnyder83 [ 04/Sep/13 ]

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

Comment by TangYong [ 05/Sep/13 ]

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

Comment by TangYong [ 05/Sep/13 ]

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

Comment by jjsnyder83 [ 05/Sep/13 ]

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.

Comment by jjsnyder83 [ 05/Sep/13 ]

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

Comment by jjsnyder83 [ 06/Sep/13 ]

Committed revision 62703

Generated at Sat Jul 30 00:09:21 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.