5 Replies Latest reply on Apr 22, 2015 5:44 AM by mkouba

Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

chrisjr Apr 21, 2015 5:52 AM

Hi,

I've been trying to resolve a broken Arquillian (embedded Tomcat 7) deployment where Weld Servlet finds a Producer bean inside a bean archive *twice*. My Arquillian WAR looks like this:

WAR: ROOT.war:
/META-INF/
/META-INF/context.xml
/WEB-INF/
/WEB-INF/lib/
/WEB-INF/lib/jandex-1.2.3.Final.jar
/WEB-INF/lib/jboss-interceptors-api_1.2_spec-1.0.0.Alpha3.jar
/WEB-INF/lib/log4j-over-slf4j-1.7.12.jar
/WEB-INF/lib/jboss-annotations-api_1.2_spec-1.0.0.Alpha1.jar
/WEB-INF/lib/logback-classic-1.0.13.jar
/WEB-INF/lib/weld-servlet-core-2.2.10.SP1.jar
/WEB-INF/lib/logback-core-1.0.13.jar
/WEB-INF/lib/weld-core-impl-2.2.10.SP1.jar
/WEB-INF/lib/guava-13.0.1.jar
/WEB-INF/lib/test-weld-1.0-SNAPSHOT.jar
/WEB-INF/lib/jboss-classfilewriter-1.0.5.Final.jar
/WEB-INF/lib/cdi-api-1.2.jar
/WEB-INF/lib/weld-environment-common-2.2.10.SP1.jar
/WEB-INF/lib/slf4j-api-1.7.12.jar
/WEB-INF/lib/weld-spi-2.2.SP4.jar
/WEB-INF/lib/jboss-logging-3.1.3.GA.jar
/WEB-INF/lib/weld-api-2.2.SP4.jar
/WEB-INF/lib/javax.inject-1.jar
/WEB-INF/lib/weld-core-2.2.10.SP1.jar
/WEB-INF/beans.xml
/WEB-INF/web.xml
/WEB-INF/classes/
/WEB-INF/classes/org/
/WEB-INF/classes/org/testing/
/WEB-INF/classes/org/testing/web/
/WEB-INF/classes/org/testing/web/TroubleIT.class
/WEB-INF/classes/org/testing/web/TroubleServlet.class

where my bean archive is called test-weld-1.0-SNAPSHOT.jar and contains the following:

META-INF/
META-INF/beans.xml
META-INF/MANIFEST.MF
META-INF/maven (etc)
org/
org/testing/
org/testing/weld/
org/testing/weld/Trouble.class
org/testing/weld/TroubleMaker.class

My beans.xml is:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
    bean-discovery-mode="annotated">
</beans>

When Arquillian tries to deploy ROOT.war, I get the following error:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/E:/Users/crankin/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/E:/workspace/arquillian-test/test-servlet/target/tomcat7-embedded/webapps/ROOT/WEB-INF/lib/logback-classic-1.0.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]
09:19:40.171 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001008: Initialize Weld using ServletContainerInitializer
09:19:40.191 localhost-startStop-1 INFO org.jboss.weld.Version - WELD-000900: 2.2.10 (SP1)
09:19:40.221 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-ENV-000020: Using jandex for bean discovery
09:19:40.501 localhost-startStop-1 INFO org.jboss.weld.Bootstrap - WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
09:19:40.571 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled
09:19:40.571 localhost-startStop-1 WARN org.jboss.weld.Interceptor - WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled
09:19:40.761 localhost-startStop-1 INFO o.j.w.e.servletTomcat - WELD-ENV-001100: Tomcat 7+ detected, CDI injection will be available in Servlets, Filters and Listeners.
09:19:40.941 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001006: org.jboss.weld.environment.servlet.EnhancedListener used for ServletContext notifications
09:19:40.941 localhost-startStop-1 INFO o.j.w.e.servletWeldServlet - WELD-ENV-001009: org.jboss.weld.environment.servlet.Listener used for ServletRequest and HttpSession notifications
Apr 21, 2015 9:19:40 AM org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Trouble as unavailable
Apr 21, 2015 9:19:40 AM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet [Trouble] in web application [] threw load() exception
org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type String with qualifiers @Trouble
  at injection point [BackedAnnotatedField] @Trouble @Inject private org.testing.web.TroubleServlet.trouble
  at org.testing.web.TroubleServlet.trouble(TroubleServlet.java:0)
  Possible dependencies:
  - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.weld.TroubleMaker.getTrouble()],
  - Producer Method [String] with qualifiers [@Trouble @Any] declared as [[BackedAnnotatedMethod] @Produces @Trouble org.testing.weld.TroubleMaker.getTrouble()]

    at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:367)
    at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
    at org.jboss.weld.bootstrap.Validator.validateProducer(Validator.java:417)
    at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:36)
    at org.jboss.weld.manager.InjectionTargetFactoryImpl.validate(InjectionTargetFactoryImpl.java:150)
    at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
    at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
    at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1137)
    at org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:51)
    at org.jboss.weld.environment.tomcat.WeldInstanceManager.newInstance(WeldInstanceManager.java:25)
    at org.jboss.weld.environment.tomcat.WeldForwardingInstanceManager.newInstance(WeldForwardingInstanceManager.java:72)
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1148)
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5262)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5550)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)
    at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1081)
    at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1877)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)

Can anyone suggest anything that might help, please? My WAR deploys fine in an ordinary Tomcat 7 container - this problem only happens during an Arquillian test. And only Weld Servlet >= 2.2.5.Final is affected, which makes me suspect the bean archive isolation.

I've already tried setting org.jboss.weld.environment.servlet.archive.isolation=false, but all this does is prevent Weld Servlet from finding my Producer bean at all.

Thanks for any suggestions here,

Chris Rankin

arquillian-test.tar.zip 5.0 KB

1. Re: Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

mkouba Apr 21, 2015 11:45 AM (in response to chrisjr)

Hi Chris,
when using an embedded container with isolation enabled you have to remove testing:test-weld from maven-failsafe-plugin classpath (the same applies to maven-surefire-plugin). Note that the default classpath also contains all project dependencies (.m2/repository/testing/test-weld/1.0-SNAPSHOT/test-weld-1.0-SNAPSHOT.jar in this case). However, disabling isolation feature worked for me as well. This worked for Weld Servlet < 2.2.4 because there was no isolation - only a "flat" bean archive (there were also two classes on the classpath, but Weld loaded only one randomly).
Actions

2. Re: Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

chrisjr Apr 21, 2015 6:13 PM (in response to mkouba)

Hi,

Thanks, this has indeed solved my problem:

<plugin>
    <artifactId>maven-failsafe-plugin</artifactId>
    <configuration>
        <classpathDependencyExcludes>
            <classpathDependencyExclude>testing:test-weld</classpathDependencyExclude>
        </classpathDependencyExcludes>
    </configuration>
    ...
</plugin>

Cheers,

Chris

3. Re: Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

mkouba Apr 22, 2015 2:39 AM (in response to chrisjr)

I'm glad it works. Note that there is nothing we can do about it on the Weld side, except for writing a new entry in the FAQ .
Actions
4. Re: Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

chrisjr Apr 22, 2015 4:03 AM (in response to mkouba)

There's nothing wrong with a new FAQ . Especially considering the amount of time I spent narrowing my problem down enough to write the test-arquillian project in the first place. It was only then that I could see that my problem began with WELD 2.2.5.Final, which lead to the release notes, and then to your blog...

The surprising thing about the actual solution is that I thought that Arquillian was supposed to isolate the classpath for the test already:

The purpose of the test archive is to isolate the classes and resources which are needed by the test from the remainder of the classpath. Unlike a normal unit test, Arquillian does not simply tap the entire classpath. Instead, you include only what the test needs (which may be the entire classpath, if that’s what you decide).

So the above statement simply cannot mean what I had assumed that it had meant, which was that only the contents of the ShrinkWrap archive would be visible to the embedded Tomcat 7 container .
Actions
5. Re: Failed Arquillian deployment with Weld Servlet >= 2.2.5.Final and bean archive.

mkouba Apr 22, 2015 5:44 AM (in response to chrisjr)

Yes, it seems that this paragraph does not apply to Tomcat embedded container. I've created [ARQ-1946] Tomcat embedded container should employ a dedicated ClassLoader - JBoss Issue Tracker to track this issue.
Actions

Go to original post