"No user transaction" warnings in FeaturesRunner unit test execution?

[Steven_Huwig1]

I'm writing unit tests for a custom operation. I have the test deployment and execution running; however there are WARN entries in the test execution log like this:

05 Mar 2014 08:58:12  WARN TransactionHelper - No user transaction
javax.naming.NamingException: UserTransaction not found in JNDI
	at org.nuxeo.runtime.transaction.TransactionHelper.lookupUserTransaction(TransactionHelper.java:83)
	at org.nuxeo.runtime.transaction.TransactionHelper.commitOrRollbackTransaction(TransactionHelper.java:278)
	at org.nuxeo.ecm.core.work.AbstractWork.rollbackAndRetryTransaction(AbstractWork.java:462)
	at org.nuxeo.ecm.core.work.AbstractWork.work(AbstractWork.java:301)
	at org.nuxeo.ecm.core.work.WorkHolder.run(WorkHolder.java:65)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

My current test annotations look like this:

@RunWith(FeaturesRunner.class)
@Deploy({"my-studio-bundle", "my-custom-plugin-bundle",
        "org.nuxeo.ecm.core.persistence",
        "org.nuxeo.ecm.platform.uidgen.core", "org.nuxeo.runtime.datasource",
})
@LocalDeploy({"my-custom-plugin-bundle:OSGI-INF/test-uid-datasource.xml"})
@Features({AutomationFeature.class, RuntimeFeature.class,
        TransactionalFeature.class, CoreFeature.class})
@RepositoryConfig(init = DefaultRepositoryInit.class, user = "Administrator")

Some more observations:

• The number of times this traceback occurs is variable. Sometimes it does not occur. Sometimes it occurs two or three times (I have four test methods). It usually occurs at least once.
• The tests behave correctly, but I think this is because I am not checking behavior specific to any transaction rollback or commit.
• I tried some TransactionalFeature unit tests provided with the Nuxeo source and they did not exhibit this behavior, so I want to figure out why my tests are showing this behavior and if it is something I should ignore, or how to correct it. I did not see anything obvious in the nuxeo-csv test annotations or configuration.

EDIT: I am trying to get the minimal set of annotations needed. This same problem shows up with only @Features({AutomationFeature.class}) (I probably added the others in an attempt to fix the tracebacks).

[ataillefer_ · Accepted solution]

Hi,

First you should know that some of the test features include each other, typically AutomationFeature includes PlatformFeature which includes CoreFeature which includes RuntimeFeature. So in your test you only need to include AutomationFeature and TransactionalFeature.

Then there is a notion of order in the features (in fact in the order the annotations declared by the feature are processed, in this case the @RepositoryConfig annotation of the TransactionalFeature declaring the PoolingRepositoryFactory), so the TransactionalFeature should be included first:

@Features({ TransactionalFeature.class, AutomationFeature.class })

Of course you only need the TransactionalFeature if you want to start / commit transactions within your test. But in this case you should remove the @RepositoryConfig annotation of your test as you need it configured as it is done in the TransactionalFeature, using the PoolingRepositoryFactory (and 'Administrator' is the default user anyway).

This might keep your test passing getitng rid of the warning.

Hope this helps!

PS: note that I just commmited in nuxeo-csv to remove the useless @RepositoryConfig in TestCSVImport as it was using the same parameters as in the TransactionalFeature.

[Steven_Huwig1]

Thanks for your help. I did realize that most of the features I have originally included were not needed. I removed everything except my @Deploy and @LocalDeploy and the AutomationFeature, and I still get the tracebacks.

[Steven_Huwig1]

I actually changed my logging output to add the thread name.

[ataillefer_]

Maybe you need the TransactionalFeature for the fulltextUpdater to not generate this warning. You can always disable listeners by injecting the EventServiceAdmin and using its API

[Steven_Huwig1]

I did notice the EventServiceAdmin class, but had trouble finding out what names to pass into setListenerEnabledFlag. The handlers I want to disable for unit tests are in a bundle produced by Studio, and simply using the names defined in the UI did not seem to have an effect.