Sample of resource adapter testing with Arquillian

[jeffmaury]

Hello,

I am willing to use Arquillian in order to unit test my home made JCA resource adapter.

However, I did not find some infos relevant to this topic in tutorials, books,...

Do you know where I can find a sample ?

Thanks

Jeff

[robert.panzer]

Hi Jeff,

If you are looking for a test of an nbound resource adapter you might want to take a look at robertpanzer/filesystemwatch-connector · GitHub

Otherwise testing an outbound resource adapter is straightforward.

Often the only problem is to define a connection factory. If you test on JBoss it is therefore key to add an ironjacamar.xml to your rar file.

KInd regards

Robert

[jeffmaury]

Thanks for the info but as a resource adapter provider, I'm looking for a solution to be valid for multi containers.

It seems to me that ironjacamar.xml is probably valid only for latest versions of JBoss (Wildfly ?)

BTW, I discovered also that the ResourceAdapterArchive does not allow to add class or packages and my RAR contains classes at the root of the archive like a JAR archive.

Jeff

[robert.panzer]

The implementation of the resource adapter does not go directly into the ResourceAdapterArchive as classes but as embedded jars.

So you should add the classes to a JavaArchive that you addAsLibrary to the ResourceAdapterArchive.

Another possibility is to addAsLibrary the JavaArchive to the EnterpriseArchive.

When I test on WebSphere I use the connection factory that WebSphere creates automatically under the JNDI name eis/<name of the MCF>.

To test on TomEE you might like http://robertpanzer.github.io/blog/2014/outboundra-test-on-arquillian-tomee.html

To summarize testing a resource adapter is not as smooth as testing EJBs or Webapps. But that just mirrors the current situation when bringing resource adapters into productive applications.

JCA currently lacks the plug and play experience that you get with EJBs or webapps.

The struggle already starts IMO when you reference a DataSource from an EJB. I always have to resolve the JNDI name in a proprietary DD.