"No user transaction" warnings in FeaturesRunner unit test execution?
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).
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
.
@Deploy
and @LocalDeploy
and the AutomationFeature
, and I still get the tracebacks.
The only other sign of trouble I see is ERROR CoreFeature - There are 0 open session(s) at tear down; it seems the test leaked -1 session(s).
at the end of my test run.
4742 [Nuxeo-Work-fulltextUpdater-1] WARN org.nuxeo.runtime.transaction.TransactionHelper - No user transaction
I don't care about full text updating for my unit test. Is avoiding using this entire set of repository features an option?
I think the ordering of feature inclusion is something for me to explore, since changing things around gives me different types of tracebacks. I think there might be a conflict between declaring the unit test annotations in the typical way, and handling <http://answers.nuxeo.com/questions/8304/can-getnextid-be-called-without-error-in-code-being-executed-by-a-featuresrunner-unit-test>. If I can disable the handler in my studio bundle that does getNextId() (or somehow mock out the call to getNextId(), then I suspect my unit test annotation/configuration can look much more like the ones in nuxeo-sample-project and nuxeo-csv.