Switchyard JtaTransactionManager on Unit Tests

[edevera]

I am trying to run some integration tests based on the SwitchYardRunner.class. I have basically adapted the camel-jms-binding quickstart to my needs, which is basically adding the transactionManager as well as the transacted parameters to the camel URI binding as shown below:

{code}

<switchyard xmlns="urn:switchyard-config:switchyard:1.0">

    <composite

            xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"

            name="camel-jms-binding"

            xmlns:swyd="urn:switchyard-config:switchyard:1.0"

            targetNamespace="urn:com:edevera:services:1.0.0">

        <service name="myService" promote="myService">

            <camel:binding.camel xmlns:camel="urn:switchyard-component-camel:config:1.0"

                                 configURI="jms://MyQueue?connectionFactory=%23JmsXA&amp;transactionManager=%23jtaTransactionManager&amp;transacted=true">

                <camel:operationSelector operationName="save"/>

            </camel:binding.camel>

        </service>

    </composite>

</switchyard>

{code}

When I execute the CamelJMSBindingTest included in this quickstart I get the following error:

{code}

java.lang.reflect.InvocationTargetException

          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

          at java.lang.reflect.Method.invoke(Method.java:597)

          at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)

          at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)

          at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)

          at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)

          at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)

Caused by: org.apache.maven.surefire.testset.TestSetFailedException: java.lang.NullPointerException; nested exception is java.lang.NullPointerException: null

          at org.apache.maven.surefire.common.junit4.JUnit4RunListener.rethrowAnyTestMechanismFailures(JUnit4RunListener.java:166)

          at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:118)

          ... 9 more

Caused by: java.lang.NullPointerException

          at org.switchyard.test.SwitchYardRunner$TestLifecycleListener.testFinished(SwitchYardRunner.java:88)

          at org.junit.runner.notification.RunNotifier$7.notifyListener(RunNotifier.java:145)

          at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)

          at org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:142)

          at org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:41)

          at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:269)

          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)

          at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)

          at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)

          at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)

          at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)

          at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)

          at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)

          at org.junit.runners.ParentRunner.run(ParentRunner.java:300)

          at org.switchyard.test.SwitchYardRunner.run(SwitchYardRunner.java:78)

          at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)

          at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)

          at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)

          ... 9 more

Results :

Tests in error:

  sendHostMessageToJMSQueue(com.edevera.CamelJMSBindingTest): Could not create a JtaTransactionManager as no TransactionManager was found in JNDI. Tried [java:jboss/UserTransaction, java:comp/UserTransaction]

{code}

Does anyone know how to prepare a TransactionManager from a Switchyard Test?

[splatch]

Hey,

By default jtaTransactionManager bean is instance of spring PlatformTransactionManager (in this case org.springframework.transaction.jta.JtaTransactionManager). If you would like to use jta then you need to modify a bit JNDI object tree during test start up. You can try the way we did for JPA:
https://github.com/splatch/quickstarts/blob/SWITCHYARD-775/camel-jpa-binding/src/test/java/org/switchyard/quickstarts/camel/jpa/binding/CamelJpaBindingTest.java#L71

[splatch]

FYI, I just created transaction mixin. You can test it before it will be moved to SY codebase by copying code https://github.com/splatch/core/tree/SWITCHYARD-886 (latest commit from this branch contains necessary mixin class).

[edevera]

That sounds really great!

[kcbabo]

Lukasz - do you think it would be useful if the MixIn had some methods for things like getting a user transaction?  MixIns can be injected into a test class and it might be useful to have something like this in a user's test class:

txMixIn.getUserTransaction()

You could even go a step further and add methods like begin(), commit(), rollback(), etc.  It would be interesting to hear from Tomo about how this might apply to JCA tests as well.

[splatch]

Sure, I can extend mixin and provide accessors for transaction objects. Didn't know it is possible to inject them.

[kcbabo]

Yep.  Here's an example for reference:

https://github.com/jboss-switchyard/quickstarts/blob/master/bean-service/src/test/java/org/switchyard/quickstarts/bean/service/WebServiceTest.java

[igarashitm]

Sorry, I just saw this

You could even go a step further and add methods like begin(), commit(), rollback(), etc.  It would be interesting to hear from Tomo about how this might apply to JCA tests as well.

IronJacamar embedded which is used by JCAMixIn, is using arjuna inside. So the transaction related interaction should be performed with it - oh wait, I have noticed I should have rebinded TransactionManager into "java:jboss" since IJ bind it into "java:/" ... I need to fix JCAMixIn for the TransactionHandler

[splatch]

Hey Tomo,

In this case we just need to put somewhere notice to don't use TransactionMixIn with JCAMixIn and rely on TransactionManager deployed by second.

[igarashitm]

One another idea is to have "embedded" flag, and create arjuna instance like your current code only when embedded=true. If embedded=false then just look it up from JNDI, and we benefit by the begin/commit/rollback method on TransactionMixIn for both cases. It avoids to spread "java:jboss/UserTransaction" String literal over everywhere.

[igarashitm]

It avoids to spread "java:jboss/UserTransaction" String literal over everywhere.

BTW, if it's the only purpose to have begin/commit/rollback on TransactionMixIn, we actually need may be just getUserTransaction().

[edevera]

Hi Lukasz,

Do you have any estimates when this TransactionMixIn will be realeased as part of Switchyard?

Thanks!

[splatch]

It's already posted in pull request. I am sure it will jump into 0.6-SNAPSHOT, I am not sure if it will go to 0.5 release.