Review Board 1.7.22

Add Unit/System Testing to Qpid JCA Project

Review Request #3540 - Created Jan. 18, 2012 and updated

Weston Price
gordon, k-wall, rajith, robbie
The following patch adds the necessary changes to add system tests as well as unit tests to the Qpid JCA subproject. Although we use the TCK (internal) to test the JCA adapter, the lack of an application server should not prohibit testing in the JCA project. While full integration testing might not be possible, we do provide a non-managed javax.resource.spi.ConnectionManager that allows us to acquire a javax.jms.Connection/javax.jms.Session etc (non-pooled, no auto XA enlistment) which in turn allows for system testing. Unit testing can also be achieved similar to the other Qpid Java sub projects. Also, this will allow us to add mock objects where appropriate without having to bring in an entire JEE environment.

Note, the JCA examples also provide a 'smoke test' like framework, however, more testing really needs to be added and maintained as was initially identified in the Qpid JCA review prior to the adapter being included in the Qpid project. 

While the Qpid JCA adapter only officially supports the C++ broker, a majority of the tests can be used with the Java Broker other than XA specific tests which can be excluded using the normal exclusion mechanism. 

To get things started I have added two tests classes:


This is a system test class with two tests that test the following JIRA's -- check for javax.jms.IllegalStateException for Session.commit() when a connection has been closed -- QpidRAMessage should call session.getSessionInternal() to determine if the underlying session has been closed prior to calling message.acknowledge().

[junit] Running org.apache.qpid.ra.QpidRAConnectionTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.75 sec


This is a unit test class that tests for the correct return value in the QpidResourceAdapter.getXAResources() call. Note, there is no corresponding JIRA for this test as it was implemented prior to the JCA being committed to the main repo.

 [junit] Running org.apache.qpid.ra.QpidResourceAdapterTest
 [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.129 sec

Note, while it might seem to be overkill to review a patch that simply adds testing to a sub-project, I had to touch a few files outside of the JCA tree and I thought a review was in order.

Java build and test-suite execution.
Review request changed
Updated (Jan. 19, 2012, 12:32 a.m.)
Whoops. Wrong diff originally uploaded. JCA test classes have now been included.
Posted (Jan. 19, 2012, 3:10 p.m.)
I've found a few nits:
/trunk/qpid/java/.gitignore (Diff revision 2)
Not sure if this files needs to be checked in.
  1. I can try using the .gitignore file already in use in the tree.
/trunk/qpid/java/build.xml (Diff revision 2)
There seems to be no actual change to this file, why check it in.
  1. I automatically remove trailing whitespaces when saving a file, this appears to be what that is.
/trunk/qpid/java/jca/example/.gitignore (Diff revision 2)
I don't know what file type .swp is, but you've added to to several .gitignore files - why not add it to a .gitignore higher in the file hierarchy.
  1. *.swp is a temp VIM file that gets generated when VIM has open files. I will add it higher in the hierarchy.
Posted (Jan. 20, 2012, 2:18 p.m.)


I'd suggest using the QpidBrokerTestCase.DEFAULT_PORT as the port number rather than hardcoding 15672.

  1. Agreed will fix.
I'd suggest a better name would be something like "testSessionCommitOnClosedConnectionThrowsException"
  1. Agreed will fix.
Whilst it is true that Session#createSession ignores the second argument (acknowledgeMode) if the first argument (transacted) is true, for me the code is more obvious if you write:

c.createSession(true, Session.SESSION_TRANSACTED);
  1. Agreed will change.
You'd normally only #acknowledge() on a message that has been received by a Consumer within a CLIENT_ACK Session.  I don't understand the meaning of acknowledging a newly created message.

I can see it serves your purpose (testing your change to call sessionInternal), but I don't think this represents useful end to end test in this form.

  1. Agree in principle, however setting up a consumer using JCA without an app server is problematic. The code was added simply to test the patch without having to write a significant amount of mock code for this one condition.