Injection in JBoss 5.1

[pnizio]

I'm currently trying to set up Arquillian for testing inside JBoss 5.1 remote container and I encountered some problems with injection. According to the doc, Arquillian should be able to inject EJBs into the test. Unfortunately this doesn't happen in my case, because I'm using non-standard naming convention (beans' names ended with Impl instead of Bean). My question is: does Arquillian support injection of custom-named beans or I have to stick to manual JNDI lookups?

Other thing that bothers me is the @Resource annotation. Are you planning to support it for JBoss remote container in future releases? It would be nice to be able to inject UserTransaction for testing components with TransactionAttribute set to MANDATORY.

[aslak]

You'll have to lookup in JNDI manually in the current release. As soon as we figure out a good way of mapping between Interface name and JNDI binding for the different servers we'll release it.

@Resource should work.. what is the problem?

http://github.com/arquillian/arquillian/blob/master/examples/junit/src/test/java/com/acme/resource/InjectionTestCase.java

[pnizio]

I checked out the test you've given and it passes. It's still in green when I change the type of injected resource to UserTransaction. Although when I try it in my own tests I get the NPE

[aslak]

What are you trying to inject?

What's your pom dependencies?

[pnizio]

I'm trying to inject UserTransaction into my test:

@Resource
private UserTransaction tx;

This works perfectly in my EJBs but not in my test cases. The tx reference is null inside test methods in runtime.

My test dependencies are following:

<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>

<scope>test</scope>
</dependency>

<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-junit</artifactId>
<version>1.0.0.Alpha4</version>

<scope>test</scope>
</dependency>

<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-jbossas-remote-5.1</artifactId>
<version>1.0.0.Alpha4</version>

<scope>test</scope>
</dependency>

<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-client</artifactId>
<version>5.1.0.GA</version>
<type>pom</type>

<scope>test</scope>
</dependency>

<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.4.8</version>

<scope>test</scope>
</dependency>

[aslak]

Yea, the problem there is that when you don't define a mappedBy="jndi-name", it will try to lookup based on the comp: namespace. So even tho UserTransaction is bound in the EJBs comp: context, the ejbs comp: context is not known outside the EJB.

Based on how the Test Execution call is done currently(http) the request comes in via a Servlet and there for not a part of the same context as the EJB. When we get support for multiple protocols(e.g. EJB remote https://jira.jboss.org/browse/ARQ-223) we can execute within the same context.

So for now you will have to add the global jndi name to the Resource lookup.

[pnizio]

Finally I got some time to check your answer. I found out that UserTransaction object is registered in both global and java:comp namespaces. Unfortunately it didn't help much. I tried the following JNDI names of which none was correct: java:comp/UserTransaction, java:/UserTransaction, comp/UserTransaction, java:comp/env/UserTransaction, java:global/comp/UserTransaction,  java:global/UserTransaction,  java:global:comp/UserTransaction,  global:java/comp/UserTransaction,  global:java:comp/UserTransaction. And probably a few others I don't remember now. All attempts failed with NPE.

Do you know what is a correct JNDI name for UserTransaction and other resources?

[jaikiran]

Try:

@Resource(mappedName="UserTransaction")
private UserTransaction ut;

[aslak]

jaikiran pai wrote:

@Resource(mappedName="UserTransaction")
private UserTransaction ut;

You beat me to it.. Just tested using "UserTransaction" and it works.

[pnizio]

OK, you're right, it works... but only when using IN_CONTAINER run mode. Otherwise it's impossible to get it working.

What a pity I have to stick to the client mode because of the pyramid of dependencies my tests need.