Issue Details (XML | Word | Printable)

Key: GLASSFISH-15721
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Sivakumar Thyagarajan
Reporter: stuartdouglas
Votes: 20
Watchers: 15

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

"injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)"

Created: 27/Jan/11 03:40 PM   Updated: 18/Jul/11 07:00 PM   Resolved: 09/Jun/11 08:26 AM
Component/s: cdi
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b05

Time Tracking:
Not Specified

File Attachments: 1. Java Archive File weld-osgi-bundle.jar (2.54 MB) 21/Feb/11 03:43 AM - mimik789

Issue Links:

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes 3_1_1-review
Participants: cbarragan, DiegoCoronel, eratzlaff, mimik789, mojavelinux, Nazrul, scatari, Scott Fordin, Sivakumar Thyagarajan, stuartdouglas, toomanyryans, vostok and vrcollins

 Description  « Hide

The Bean Deployment Archive visibility graph does not correctly implement the spec.

Beans in WEB-INF/lib are made availible to beans in WEB-INF/classes, however the converse is not true (i.e. beans is WEB-INF/classes cannot be injected into WEB-INF/lib injection points), and beans in one jar in WEB-INF/lib cannot be injected into beans in a different jar in WEB-INF/lib.

According to the CDI and EE6 Platform spec both of these should work.

mojavelinux added a comment - 27/Jan/11 11:22 PM

Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other.

These tests can be run from the root of the Solder project as follows:

mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest
mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.

Sivakumar Thyagarajan added a comment - 01/Feb/11 10:29 AM

Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.

Sivakumar Thyagarajan added a comment - 02/Feb/11 02:12 AM

This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1.

Release note/Workaround:
Until then the application could be repackaged such that either:

  • Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar
  • All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes].

Sivakumar Thyagarajan added a comment - 11/Feb/11 06:19 AM - edited

FWIW, Weld has fixed the root issue in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available.

I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this).

mimik789 added a comment - 11/Feb/11 06:48 AM

I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test).
mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest

first test (TypeVisibilityWithinBeanArchiveTest) passes OK

but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(
at org.jboss.weld.bootstrap.Validator.validateBean(
at org.jboss.weld.bootstrap.Validator.validateRIBean(
at org.jboss.weld.bootstrap.Validator.validateBeans(
at org.jboss.weld.bootstrap.Validator.validateDeployment(
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(
at org.glassfish.weld.WeldDeployer.event(

having same issue?

vostok added a comment - 16/Feb/11 02:35 AM

I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs!

Tags: 3_1-exclude 3_1-release-notes


----- Solving this bug is being excluded from 3.1 final???

eratzlaff added a comment - 16/Feb/11 06:36 AM

It would be nice to have this bug fix for glassfish 3.1 release.

mimik789 added a comment - 21/Feb/11 03:43 AM

You may be interested with this good news:

for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from:

DiegoCoronel added a comment - 10/Mar/11 05:52 AM

The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked.
My war classes cant inject my jar classes.

It works fine in glassfish 3.0.1 final.

In my specific case i have this scenary

– MyJarProject1.jar (depends:MyFramework, myWebModule.war)
– MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war)
– MyFramework.jar (depends:myWebModule.war)

where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager.

Scott Fordin added a comment - 23/Mar/11 06:41 PM

Need more info to add issue to 3.1 Release Notes.

Nazrul added a comment - 21/Apr/11 11:11 AM

It would be useful to look into this issue for 3.1.1

vrcollins added a comment - 05/May/11 01:29 PM

I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors.

toomanyryans added a comment - 10/May/11 02:51 PM

I think I've been running into this bug. Assume I have two .jars:


If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux?

I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue.

Scott Fordin added a comment - 17/May/11 11:43 AM

Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes.

scatari added a comment - 24/May/11 03:43 PM

Fix expected by first week of June.

Sivakumar Thyagarajan added a comment - 09/Jun/11 08:26 AM

This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk.

Through svn revision 47397, I have also added the following developer tests to cover this scenario

cbarragan added a comment - 14/Jul/11 09:44 AM

As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue.

I have an EAR with an ejb module and some jars in the lib directory.
A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem?

Sivakumar Thyagarajan added a comment - 18/Jul/11 07:00 PM


As per section 5.1 of the CDI 1.0 specification:
"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection.