Arquillian fails to inject dependencies after the first test class

Question

I have a slightly weird problem. I'm currently using Arquillian (1.1.0.Final) together with Embedded GlassFish (3.1.2.2). I used following guide to setup my little test project. Everything worked fine with the integrated Derby database. My real application uses PostgreSQL as a database, so I configured my GlassFish resources as follows:

    <!-- See http://jdbc.postgresql.org/documentation/91/ds-cpds.html -->
    <jdbc-connection-pool name="MyPostgresqlPool"
                          res-type="javax.sql.DataSource"
                          datasource-classname="org.postgresql.ds.PGSimpleDataSource"
                          is-isolation-level-guaranteed="false">

        <property name="user" value="..." />
        <property name="databaseName" value="..." />
        <property name="password" value="..." />
        <property name="serverName" value="..." />
        <property name="portNumber" value="..." />

    </jdbc-connection-pool>

And I access the persistence context and the user transaction as described in above guide:

@RunWith(Arquillian.class)
public class AddressModuleTest extends BaseTest {
    @PersistenceContext
    protected EntityManager em;

    @Inject
    protected UserTransaction utx;

    @Before
    public void setUp() throws Exception {
        utx.begin();
        em.joinTransaction();
    }

    @After
    public void tearDown() throws Exception {
        utx.rollback();
    }

 [ ... snip ...]
}

If I run my test class (AddressModuleTest, please note that "BaseTest" has a static method annotated with @Deployment for Arquillian) everything is fine and I can read my data from the PostgreSQL database.

Unfortunately, If I create a second test class it won't work:

@RunWith(Arquillian.class)
public class CommunicationModuleTest extends BaseTest {
    @PersistenceContext
    protected EntityManager em;

    @Inject
    protected UserTransaction utx;

    @Before
    public void setUp() throws Exception {
        utx.begin();
        em.joinTransaction();
    }

    @After
    public void tearDown() throws Exception {
        utx.rollback();
    }

    [ ... snip ... ]
}

Maven (respectively surefire) gives me the following error:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.758 sec <<< FAILURE!
loadMessageDAO(package.CommunicationModuleTest)  Time elapsed: 0.027 sec  <<< ERROR!
java.lang.RuntimeException: Could not inject members
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135)
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78)
    at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
    at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ ... snip ... ]

.. with the following root exception:

Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null
    at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:678)
    at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136)
    at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686)
    at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695)
    at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:106)
    at org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServicesImpl.java:134)
    at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:46)
    at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:102)
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:145)
    at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:125)
    ... 79 more

I went back to the guide and tried to reproduce my issue with their code - with no sucess (i.e. they are not affected by my problem). Therefore I assume that either my UserTransaction handling is wrong or it is an issue with my PostgreSQL configuration. I tried different datasources, namely

org.postgresql.ds.PGSimpleDataSource
org.postgresql.ds.PGPoolingDataSource

As well as javax.xa.XADataSource together with org.postgresql.xa.PGXADataSource with no success.

Does somebody have a clue what's wrong? I have to admit that I'm (very) inexperience with different DataSources as well as Transaction Management.

UPDATE

It looks as if the issue is independent of PostgreSQL as it happens on MySQL (MariaDB) as well. The stacktrace is the same, so I assume the issue lies within my Transaction Management..

Kind regards and many thanks for your help

stupidSheep

score 8 · Accepted Answer · answered Sep 11 '13 at 11:22

This bug was introduced by ARQ-1071 in 1.0.4.Final and persists in current version (1.1.1.Final). The reason is that all ThreadLocal occurences were replaced by InheritableThreadLocal to fix a NPE on @Timeout usages.

The proposed fix consists on revert just one occurence of InheritableThreadLocal to ThreadLocal like it has been done on following Pull Request: https://github.com/arquillian/arquillian-core/pull/53

Please, vote on the issue to be released on next 1.1.2.Final version: https://issues.jboss.org/browse/ARQ-1458

score 2 · Answer 2 · answered Apr 27 '14 at 20:32

The commit to solve this issue in 1.0.3.Final was reverted in subsequent versions, and was not until version 1.1.4.Final when it was finally solved.

<dependency>
    <groupId>org.jboss.arquillian</groupId>
    <artifactId>arquillian-bom</artifactId>
    <version>1.1.4.Final</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

score 1 · Answer 3 · answered Aug 02 '13 at 09:53

1

I have a similar problem (the only difference is that I'm getting the message "WELD-001456 Argument resolvedBean must not be null"). Resolved beans are stored in an instance of the class org.jboss.weld.manager.BeanManagerImpl that is shared between all tests in micro deployment. In my case the cause of failure is that when some test finished, its thread is staying bound with old instance of TestRunnerAdaptor that is linked to the already cleaned bean manager (see method org.jboss.weld.manager.BeanManagerImpl.cleanup()). If some test from next micro deployment will use one of such threads it fail. The problem is related to Arquillian with version > 1.0.3.Final (in new versions field type org.jboss.arquillian.junit.State.lastCreatedRunner is changed from ThreadLocal to InheritableThreadLocal and now method org.jboss.arquillian.junit.State.isLastRunner() always returns false).

I don't know how to solve this problem. The only way is use Arquillian 1.0.3.Final.

answered Aug 02 '13 at 09:53

briarheart

1,906
2
19
33

Hi postiveCoder! Thanks for your answer! I changed my version to Arquillian 1.0.3.Final and now it works. I'll ask in the Arquillian Community (JBoss) if they can help out.. (see https://community.jboss.org/message/830718) and keep you posted if I know anything more! – stupidSheep Aug 02 '13 at 12:35
Neither on SO nor in the Arquillian Forums somebody knew an answer, so I'll accept yours as it does provide a workaround to my issue :) – stupidSheep Aug 08 '13 at 10:29
Thank you. It seems only we have this issue. :) – briarheart Aug 08 '13 at 20:50
Hi positiveCoder! I "unaccepted" your answer as zyc fixed the issue (I haven't tested it yet as I am currently not working on the same project). – stupidSheep Sep 12 '13 at 16:19

Arquillian fails to inject dependencies after the first test class

3 Answers3