CDI injection of managed bean from java module

[woelfle]

We have an JEE 6 enterprise application running in a JBoss 7.2.0 Alpha1 container with following structure:

    app.ear

      services.jar (EJB Module)

        beans.xml

        ServiceA.java

      lib/domain.jar (Java module)

        beans.xml

        SomeDomainLogic.java

ServiceA contains a field of type 'SomeDomainLogic'. This field should be injected by CDI. Therefore there is a @Inject annotation at the field. When starting up the container it fails with following exception:

    10:21:37,374 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.subunit."app.ear"."services.jar".component.ServiceA.WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.subunit."app.ear"."services.jar".component.ServiceA.WeldInstantiator: Failed to start service

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]

    at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]

    Caused by: java.lang.RuntimeException: JBAS016060: Could not resolve CDI bean for injection point private SomeDomainLogic ServiceA.logic with qualifiers []

    at org.jboss.as.weld.injection.WeldEEInjection.createWeldEEInjection(WeldEEInjection.java:161)

    at org.jboss.as.weld.injection.WeldManagedReferenceFactory.start(WeldManagedReferenceFactory.java:117)

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

    ... 3 more

If the class is moved into the 'services.jar' EJB Module everything works fine. But when it resides in the 'domain.jar' Java module it is not found. Has anyone an idea what we are doing wrong? Or is this a bug?

[atiyou]

Hi,

can anyone answer plz ?

I have the same problem but with arquillian test case,

XXX-core-api

     ConfigurationProducer.java (of XMLConfiguration)

     XMLConfig.java(qualifier)

XXX-cxf-testsuite

     CXFServlet.java that inject XMLConfiguration with XMLConfig qualifier

=> stack trace

JBAS016060: Could not resolve CDI bean for injection point org.apache.commons.configuration.XMLConfiguration

xx.remoting.jaxws.client.test.CXFServlet.configuration with qualifiers [@xx.core.configuration.XMLConfig]

[nickarls]

Hmm. You could check the JSR-299 specification for the visibility rules. I'm not sure if a bean in an ejb module is supposed to see the deployment archive in the lib...

[atiyou]

for my case,

i don't have ejb module, i have XXX-core-api module that content the qualifier and producer of XMLConfiguration

And in my testsuite case, i inject XMLConfiguration to my servlet

=> So it only happens in the arquillian test,  because in my webapp application i have the same configuration of injection and it works !

i build my webarchive like this :

          WebArchive war = ShrinkWrap.create(WebArchive.class, archiveName + ".war");    

        File[] libs = Maven.resolver()

             .loadPomFromFile("pom.xml").resolve(

                     "xxx.core:xx-core-api"

                     ,"xxx.cxf:xx-cxf-api"

             ).withTransitivity().as(File.class);

        war.addAsLibraries(libs).as(JavaArchive.class);

and my cxfServlet in the testsuite packages look's like :

Named

@WebServlet(name="MyServlet", loadOnStartup = 1, urlPatterns="/services/*")

public class CXFServlet extends  CXFNonSpringServlet  {

    @Inject

    @XMLConfig

    XMLConfiguration configuration;

Any idea

[nickarls]

Output the test archive so you can see what's really in there.

[atiyou]

i did, i have checked in the real archive deployed on as7, and the test archive content as well the jar that have the producer class !

clientWSProxyTest.war:

/WEB-INF/

/WEB-INF/beans.xml

..

/WEB-INF/lib/xxx-core-api-139066798746330088.jar

/WEB-INF/classes/xx/remoting/jaxws/client/test/CXFServlet.class

It's a strange behavior and the exception is not clear, I have not found anything about it

Notice that the test suite works with arquillian-weld-ee-embedded profile !

[nickarls]

Perhaps toss the problem around on the arquillian forum...

[atiyou]

Hi,

I really need a help for this problem,

I have an EAR module that content just a war, so when i deploy it on jboss 7.1.1 i get this : WELD-001409 Ambiguous dependencies for type ...

because i inject a bean without specifying implementation at injection point, but i do it on WEB-INF/beans.xml using solder markers :

<s:modifies />

<s:Inject/>

            <s:Exact>

in order to define implementation class i want to load.

So when i checked the log, it seems like Solder do not process war's beans.xml, i don't know why and i do not found any clean solution for this !

I found this : https://issues.jboss.org/browse/SOLDER-222 (nobody answers)

Structure

    app.ear

          xx-webapp

               WEB-INF/beans.xml

               ...

Logs :

12:21:07,817 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016008: Starting weld service for deployment design-ear.ear

12:21:08,098 INFO  [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-4) Solder Config XML provider starting...

12:21:08,098 INFO  [org.jboss.solder.config.xml.bootstrap.XmlConfigExtension] (MSC service thread 1-4) Loading XmlDocumentProvider: org.jboss.solder.config.xml.bootstrap.ResourceLoaderXmlDocumentProvider

12:21:08,114 INFO  [org.jboss.solder.Version] (MSC service thread 1-4) Solder 3.2.0-SNAPSHOT (build id: 3.2.0-SNAPSHOT)

12:21:08,629 INFO  [org.jboss.solder.core.CoreExtension] (MSC service thread 1-4) Preventing class org.jboss.seam.security.external.openid.OpenIdProviderInApplicationScopeProducer from being installed as bean due to @Veto annotation

/...

Any idea ??

tks