Bug 1028062 - Beans from a non-CDI module are loaded when adding the module as a dependency to a Weld deployment
Beans from a non-CDI module are loaded when adding the module as a dependency...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CDI/Weld (Show other bugs)
6.1.0,6.2.0,6.1.1
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: baranowb
Marek Schmidt
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-07 10:11 EST by Pedro Igor
Modified: 2014-07-30 13:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-30 13:45:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pedro Igor 2013-11-07 10:11:28 EST
Description of problem:

Beans from a non-CDI module are loaded when adding the module as a dependency to a Weld deployment. However, WildFly behaves differently and does not allow this.

After discussing about this difference between EAP and WildFly at #wildfly-dev, the recommendation from Jozef Hartinger was to follow WildFly behavior which seems to be the right one.

Version-Release number of selected component (if applicable):


How reproducible:

Just try to add a non-CDI module as a dependency to a Weld deployment, and use a bean from the module in a producer method, for example.

Eg.:

ModuleSpecification moduleSpec = deployment.getAttachment(Attachments.MODULE_SPECIFICATION);
ModuleLoader moduleLoader = deployment.getAttachment(Attachments.SERVICE_MODULE_LOADER);

ModuleDependency nonCDIModuleDependency = new ModuleDependency(moduleLoader, NON_CDI_MODULE_IDENTIFIER, false, true, true, false);

moduleSpec.addUserDependency(dependency);


Steps to Reproduce:
1.
2.
3.

Actual results:

Beans from a non-CDI module are loaded even if the META-INF/beans.xml is not present inside the module.

Expected results:

Beans should be recognized/loaded only if META-INF/beans.xml is present inside the module.

Additional info:

The following repository provides all the necessary code and integration tests to see this issue in action:

https://github.com/picketlink/picketlink-as-subsystem/tree/EAP_6.2

The failing test is test.org.picketlink.as.subsystem.idm.integration.IdentityConfigurationProducerTestCase.

The test above uses a @Producer for a bean located at the non-CDI module (without the META-INF/beans.xml). In this case it will pass.

There is also a WildFly branch with the same code and tests:

https://github.com/picketlink/picketlink-as-subsystem/tree/WFLY_8

The same test fails when using this branch, which is the expected behavior.
Comment 2 Ron Šmeral 2014-07-30 13:18:51 EDT
Currently, the behaviour seems to be consistent (and IMHO correct) on both, EAP 6.3.0.ER10 and WildFly 8.1.0.Final.

I've tested the scenario in an independent test (not the PicketLink one) and it seems to work as would be expected:
- there's a WAR deployment with:
  - a test bean with an injection point for X
  - a producer for X
  - beans.xml
  - MANIFEST.MF declaring a dependency on the static module
- there's a non-CDI static module in the server with:
  - the class X
  - (NO beans.xml here)

Expectations:
- the producer should be able to find the class X, due to the declared class-loading dependency in MANIFEST.MF
- the class X is produced and becomes a bean (is injectable into beans in the deployment), because the producer is in a bean archive and sees class X

The test confirms these expectations in current WF and EAP.

IIUC, these expectations are in contradiction with the expectations mentioned in the first comment.

(The situation is obviously different, when also the producer is in the non-CDI static module. It then should not and does not produce a bean X.)

Is this still an issue?
Comment 3 Pedro Igor 2014-07-30 13:37:45 EDT
It is fine now. got the same results with latest versions.
Comment 4 Ron Šmeral 2014-07-30 13:45:50 EDT
Thanks, I'll close this then.

Note You need to log in before you can comment on or make changes to this bug.