"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).

0 votes

1 answers

2927 views

ANSWER

Copy URL

ANSWERS

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`.

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.

0 votes

Copy URL

Steven Huwig

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.

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.

03/05/2014

Steven Huwig

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

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?

03/05/2014

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: setBlockAsyncHandlers, setBlockSyncPostCommitHandlers, setListenerEnabledFlag (to disable a specific listener).

03/05/2014

Steven Huwig

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.

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.

03/05/2014

Authentication Required

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

Invite people to answer

What's new in Quandora?