NullPointerException in SpringTransactionHooks when upgrading to 1.1.5

[mmalmeida]

Running the tests after upgrading from 1.1.3 to 1.1.5 yields the following exception:

java.lang.NullPointerException
    at cucumber.api.spring.SpringTransactionHooks.obtainPlatformTransactionManager(SpringTransactionHooks.java:65)
    at cucumber.api.spring.SpringTransactionHooks.rollBackTransaction(SpringTransactionHooks.java:60)
    at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at cucumber.runtime.Utils$1.call(Utils.java:35)
    at cucumber.runtime.Timeout.timeout(Timeout.java:12)
    at cucumber.runtime.Utils.invoke(Utils.java:31)
    at cucumber.runtime.java.JavaHookDefinition.execute(JavaHookDefinition.java:59)
    at cucumber.runtime.Runtime.runHookIfTagsMatch(Runtime.java:213)
    at cucumber.runtime.Runtime.runHooks(Runtime.java:201)
    at cucumber.runtime.Runtime.runAfterHooks(Runtime.java:195)
    at cucumber.runtime.model.CucumberScenario.run(CucumberScenario.java:42)
    at cucumber.runtime.junit.ExecutionUnitRunner.run(ExecutionUnitRunner.java:83)
    at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:63)
    at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:18)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at cucumber.runtime.junit.FeatureRunner.run(FeatureRunner.java:70)
    at cucumber.api.junit.Cucumber.runChild(Cucumber.java:82)
    at cucumber.api.junit.Cucumber.runChild(Cucumber.java:41)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at cucumber.api.junit.Cucumber.run(Cucumber.java:87)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Originally posted in https://groups.google.com/forum/#!topic/cukes/SjFK1QW2qE0

[mmalmeida]

I believe this might be due to the fact that the class does not have @ContextConfiguration("classpath:cucumber.xml") . If you create a completely equal class but apply the ContextConfiguration to it, the error will disappear.

Two related comments:

1. Writing @ContextConfiguration("classpath:cucumber.xml") on every stepdef and hook seems very cumbersome. In addition, if you need to define the cucumber.xml file on the hook the hook will be limited to usages with that specific file name.

2. This might not have been caught because I believe the example in examples/spring-txn/src/test/java/cucumber/examples/spring/txn/RunCukesTest.java is wrong - the hook should be "cucumber.api.spring" and not "cucumber.runtime.java.spring.hooks"

[pasviegas]

hey @ffbit do you know anything about the spring-txn example being broken?

[mmalmeida]

@pasviegas, @ffbit - The test on master is passing - but this is due to the fact that the Hook is not being called (the path in glue is wrong, it was changed in 1.1.1). See my branch above, where the hook path was corrected and the test consequently fails.

[anaMZ]

Hello,
I have the same error. Have you fixed it or do you know a workaround?
Thank you!

[ffbit]

I'm on vocation without my laptop (I'm back on Monday).
I ran all the examples when the #632 and #633 PR were made. Only the wicket example was red.

I MUST write the Spring migration guide, I promised that this summer, but haven't done yet.

[mmalmeida]

@ffbit - did you run the examples with the correct spring hook path, though (as in the commit I posted above)? As this definitely makes the test fail!

[ffbit]

I can't answer this question until I get to my laptop next Monday.

[brasmusson]

Hi, @ffbit and others, I wrapped the glue path change of the spring-txn example in a pull request (#644), so now the error in the example is clearly shown on the two Travis builds that run the examples (openidk6 and openjdk7).

[ffbit]

@brasmusson thanks for the clarification

[ffbit]

Hi, I've been trying to fix the issue and here are my findings.

I got rid of the NPE, by turning the c.a.s.SpringTransactionHooks into a Spring bean.

Then I faced another problem

org.springframework.beans.factory.NoSuchBeanDefinitionException:
  No qualifying bean of type [org.springframework.transaction.PlatformTransactionManager] is defined
...

@pasviegas, could you please correct me if I went wrong.
I found that there are two separate application context types in:

• c.r.j.s.SpringFactory
• every step definition class marked with a @*Configuration annotation.

The first one is neither a parent nor a child for the second one and they live their own lives.
So, in the first case SpringTransactionHooks's application context can't resolve the needed PlatformTransactionManager dependency, and in the second case the needed dependency is present but unreachable.

As a summary I can send a pull request solving the NPE and we can start solving the NoSuchBeanDefinitionException.

WDYT?

[pasviegas]

No, this shouldn't be the case.
Every execution should be using the same context and cleaning it when it finishes.
I will take a look as soon as I get home. Can you open a branch an send the PR?

[ffbit]

@pasviegas here is the #649 PR.

[ffbit]

@pasviegas I also can provide a proof that there are two separate application contexts, if it's necessary.

[devgrok]

In terms of spring-ness, I think it might be a better user experience to mimic or at least adapt the rules used by spring-test's SpringJUnit4ClassRunner.
I haven't attempt this yet but here's what i'm going to try:

@ContextConfiguration should only be read off classes with @RunWith(Cucumber.class) / @CucumberOptions

• as it make sense that the dev will want to group common feature sets together with the same classes mocked / stubs etc etc.
  This allows steps to be reused but also only one instance of the spring context init'd (if the context isn't drtied)
  For each @RunWith(Cucumber.class) (feature set) class, use spring-test to manage the spring context. Then create a child application context, in which the step definitions & listeners defined.
  The reason for the subcontext is that it allows the same master context (cucumber.xml to exist and remain for the entire test cycle).
  Also, it's more spring-y to instantiate the step classes (which should be automatically defined as scenario scoped if not already defined/annotated) using spring instead of reflection
  (I haven't fully considered the listeners here)

This sounds like work to do so I'll give it a stab and upload if it proves to be a valid soluion

[robertcosgrove]

Can't seem to find any information on this issue besides here. Was this something that has been fixed in a later version or is it still an existing defect?

[aslakhellesoy]

This defect has not been fixed yet. The latest release is currently 1.1.6, and the defect exists there as well.

[nieldw]

I got around this issue for now by doing exactly what @patrickmcmichael originally described in this comment on #46, which originally led to this feature.

[aslakhellesoy]

If you can, please join here Mon, May 12, 3:00 PM - 4:00 PM to discuss: https://plus.google.com/u/0/events/cstdgkbvp61g7gld8lejsap4j3o

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.