Issue Details (XML | Word | Printable)

Key: GLASSFISH-20793
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: jjsnyder83
Reporter: replicant77
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

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

Created: 03/Sep/13 02:39 PM   Updated: 06/Sep/13 03:07 PM   Resolved: 06/Sep/13 03:07 PM
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive GLASSFISH-20793_demo.zip (7 kB) 04/Sep/13 04:29 AM - TangYong

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


Tags: jsf glassfish4 weld cdi
Participants: jjsnyder83, Manfred Riem, replicant77 and TangYong


 Description  « Hide

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



TangYong added a comment - 03/Sep/13 03:04 PM

Component/s should be CDI.


Manfred Riem added a comment - 03/Sep/13 03:08 PM

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


TangYong added a comment - 03/Sep/13 03:21 PM

Change Component/s into CDI


TangYong added a comment - 04/Sep/13 04:29 AM - 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


TangYong added a comment - 04/Sep/13 06:34 AM

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.


replicant77 added a comment - 04/Sep/13 07:50 AM - 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(); }

}


TangYong added a comment - 04/Sep/13 08:16 AM

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


TangYong added a comment - 04/Sep/13 09:46 AM

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


jjsnyder83 added a comment - 04/Sep/13 01:10 PM

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


TangYong added a comment - 05/Sep/13 02:11 AM

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


TangYong added a comment - 05/Sep/13 02:23 AM

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


jjsnyder83 added a comment - 05/Sep/13 11:11 AM

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.


jjsnyder83 added a comment - 05/Sep/13 09:53 PM

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


jjsnyder83 added a comment - 06/Sep/13 03:07 PM

Committed revision 62703