Bug 988093 - CDI injection across EAP 6.1 modules does not resolve dependecies
CDI injection across EAP 6.1 modules does not resolve dependecies
Status: CLOSED DUPLICATE of bug 927895
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CDI/Weld (Show other bugs)
6.1.0
Unspecified Unspecified
urgent Severity urgent
: ER4
: EAP 6.1.1
Assigned To: Stuart Douglas
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-24 13:41 EDT by Pedro Zapata
Modified: 2013-10-24 11:30 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-06 03:23:48 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-1746 Major Resolved CDI beans in static modules cannot see each other 2016-09-29 03:04 EDT
JBoss Issue Tracker WFLY-1854 Major Open web-fragment.xml not loaded from a static module 2016-09-29 03:04 EDT

  None (edit)
Description Pedro Zapata 2013-07-24 13:41:34 EDT
Description of problem:

In the BRMS/BPMS products we are creating a modular layout to deploy on EAP 6.1.
We have found the issue that CDI dependencies across modules are not working, failing with and 'Unsatisfied dependencies' exception.

From several email discussions, it appears this is known issue but still has no solution. 

We need a solution or a valid workaround for this in order to test any modular deployment. This is blocking Modularization work on EAP.

This is a critical issue for creating modularized deployments for BPMS/BRMS (and probably for other products as well), since some of the modules make use of CDI to inject dependencies.

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

How reproducible:
Always in our tests. Apparently they are well configured.

Steps to Reproduce:
General scenario.

1. Create a layer
2. Create several modules
3. Create injection dependencies across modules
4. Create war with dependency to module

Actual results:
WELD-001408 Unsatisfied dependencies

Expected results:
No exception, same behaviour as all jars in WEB-INF/lib or in a single module.

Additional info:

18:04:28,248 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."kie-wb.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."kie-wb.war".WeldStartService: Failed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Paths] with qualifiers [@Default] at injection point [[field] @Inject private org.kie.workbench.common.screens.datamodeller.backend.server.DataModelerServiceImpl.paths]
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
        at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379)
        at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:64)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        ... 3 more
Comment 1 John Doyle 2013-07-24 14:35:01 EDT
6.1 included a feature for deployments to receive CDI injections of classes in Modules, but there was a requirement to declare the service (resolved in 6.1.1).  Does this specific issues fail because of injection from module to module and the deployment is just used to show the error?

https://bugzilla.redhat.com/show_bug.cgi?id=927895
Comment 2 Marek Schmidt 2013-07-25 10:27:17 EDT
I believe this use case works if the WAR depends on all the modules, e.g.:

foo module with Foo bean injecting Bar
bar module with Bar bean injecting Car
car module with Car

Dependencies: foo meta-inf,bar meta-inf,car meta-inf

(at least according to my simplistic test case)

Can you confirm this? It might be a more specific problem than described if that doesn't work.
Comment 4 Pedro Zapata 2013-07-26 14:43:21 EDT
The current status is the following: after applying Marek's workaround, the original errors have dissapeared.

I've been able to successfully deploy BPMS on EAP 6.1.1 ER3 as a combination of modules (JBPM, DROOLS, KIE, for core functions) and WAR (workbench & web tooling), which is the targeted layout. The application starts and I'm able to log in and do basic navigation. There are issues that are probably related to missing dependencies and other application related stuff, but apparently no blocking issues have appeared.

However, the same deployment on EAP 6.1 final fails to deploy when trying to resolve a different set of CDI dependencies. Example:

WELD-001409 Ambiguous dependencies for type [Event<BuildResults>] with qualifiers [@Default] at injection point [[parameter 4] of [constructor] @Inject public org.guvnor.common.services.builder.BuildServiceImpl(Paths, POMService, ExtendedM2RepoService, Event<BuildResults>, Event<IncrementalBuildResults>, ProjectService, LRUBuilderCache, Event<DeployResult>)]. 

Possible dependencies [[Implicit Bean [javax.enterprise.event.Event] with qualifiers [@Default], Managed Bean [class org.jbpm.shared.services.impl.events.JbpmServicesEventImpl] with qualifiers [@Any @Default]]]

The class BuildServiceImpl (living in the WAR file) [1] has an injection point of type   final Event<BuildResults> buildResultsEvent

However, possible choices listed include: 
       - Implicit Bean [javax.enterprise.event.Event] 
       - JbpmServicesEventImpl, which is marked with a @Veto annotation [2]

@Veto
public class JbpmServicesEventImpl<T> implements Event<T>, Serializable {

It looks like the @Veto annotation for a class defined in a module is being ignored in EAP 6.1.0 but not in EAP 6.1.1.

Can you confirm wheather this is the expected behaviour in EAP 6.1 or is a known issue?
         
-------------------------------
[1] https://github.com/droolsjbpm/guvnor/blob/fe56a287bf6a5fb2b100fb7809a972d6c4674aea/guvnor-project/guvnor-project-builder/src/main/java/org/guvnor/common/services/builder/BuildServiceImpl.java

[2] https://github.com/droolsjbpm/jbpm/blob/cb19c4227dca205829ccfa35a1ecdc587cf1b702/jbpm-services/jbpm-shared-services/src/main/java/org/jbpm/shared/services/impl/events/JbpmServicesEventImpl.java
------------------------------

20:02:46,684 INFO  [org.jboss.errai.reflections.Reflections] (Thread-83) Reflections took 820 ms to scan 91 urls, producing 801 keys and 4196 values [using 2 cores]
20:02:50,721 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."kie-wb.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."kie-wb.war".WeldStartService: Failed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [Event<BuildResults>] with qualifiers [@Default] at injection point [[parameter 4] of [constructor] @Inject public org.guvnor.common.services.builder.BuildServiceImpl(Paths, POMService, ExtendedM2RepoService, Event<BuildResults>, Event<IncrementalBuildResults>, ProjectService, LRUBuilderCache, Event<DeployResult>)]. Possible dependencies [[Implicit Bean [javax.enterprise.event.Event] with qualifiers [@Default], Managed Bean [class org.jbpm.shared.services.impl.events.JbpmServicesEventImpl] with qualifiers [@Any @Default]]]
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:314)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163)
        at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:379)
        at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:64)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
        ... 3 more
Comment 5 John Doyle 2013-07-29 09:43:30 EDT
Pedro, I can't answer that question for you, I don't have that level of knowledge.  Perhaps Stewart can respond.
Comment 6 John Doyle 2013-07-29 09:44:49 EDT
Pedro, what is the workaround?  Can we describe or link it here so that someone else who hits this can resolve their issue?
Comment 7 Stuart Douglas 2013-07-29 09:58:58 EDT
I believe the EAP 6.1 problem would be caused by https://issues.jboss.org/browse/WFLY-1370
Comment 10 Marek Schmidt 2013-08-05 07:58:55 EDT
The issue with CDI portable extensions not loading from a module is a known issue in EAP 6.1.0, see https://bugzilla.redhat.com/show_bug.cgi?id=927895
Comment 12 Pedro Zapata 2013-08-05 10:04:26 EDT
This particular issue have been workarounded by adding the files into META-INF of Web-application. We have also checked this particular issue has been fixed in EAP 6.1.1.

There are some other issues regarding JBoss Solder initialization in EAP 6.1.0.

We have added Solder as a module in bpms layer.

However, the web-fragment.xml file contained in solder-impl-3.2.0.Final.jar does not seem to be recognized and loaded by the container. The side effect of this is that some servlets / filters / listernes declared in this fragment are not initialized. 

We have tried to workaround this by adding this fragment to the web.xml webapp, but classloader issues arise during injections. 

Do you know any issue related tho this in EAP 6.1.0, or anything special that needs to be done? The 3.0 spec states that only  this fragment needs to be declared in META-INF from jar.
Comment 13 Scott Mumford 2013-08-05 20:06:55 EDT
Does this issue need a Release Note of its own, or since it was caused by bug 927895, does the note for that bug suffice?

This bug can get a shoutout in the note for 927895 if needed.
Comment 14 Marek Schmidt 2013-08-06 03:23:48 EDT
Can you please open a new BZ for the web-fragment.xml issue?

I am closing this one as a duplicate of 927895, as that seems to be the real problem and is confirmed fixed in EAP 6.1.1.ER3. Feel free to reopen with additional information if you don't agree.

*** This bug has been marked as a duplicate of bug 927895 ***
Comment 15 JBoss JIRA Server 2013-10-24 11:30:27 EDT
Jozef Hartinger <jharting@redhat.com> updated the status of jira WFLY-1746 to Coding In Progress

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