[
https://issues.apache.org/jira/browse/OOZIE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter reopened OOZIE-2386:
----------------------------------
[~rohini], putting {{XConfiguration.initalized = false;}} in {{setUp()}}
doesn't always work because we then call {{super.setUp()}}, which does a whole
bunch of things. The tests themselves also do some things with {{Services}}.
If any of those calls {{new XConfiguration()}}, it will initialize, and break
the test. (in fact, it can now break both tests)
I think the safest fix here is to add {{XConfiguration.initalized = false;}}
right before the calls to {{new XConfiguration()}} to ensure that nothing else
can interfere.
> org.apache.oozie.util.TestXConfiguration.testSubstituteVar is flakey
> --------------------------------------------------------------------
>
> Key: OOZIE-2386
> URL: https://issues.apache.org/jira/browse/OOZIE-2386
> Project: Oozie
> Issue Type: Bug
> Components: tests
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Fix For: trunk
>
> Attachments: OOZIE-2386.001.patch, OOZIE-2386.002.patch,
> OOZIE-2386.ammendment.patch
>
>
> {{org.apache.oozie.util.TestXConfiguration.testSubstituteVar}} is flakey.
> {noformat}
> junit.framework.AssertionFailedError: Fail to apply substitution depth
> at junit.framework.Assert.fail(Assert.java:50)
> at
> org.apache.oozie.util.TestXConfiguration.testSubstituteVar(TestXConfiguration.java:223)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is another case of a static variable persisting between unit tests.
> {{XConfiguration#initSubstituteDepth()}} gets called when you create an
> {{XConfiguration}} object, but there's an {{initialized}} static variable to
> make it only happen once. A different test,
> {{XConfiguration#testSubstituteVarUnlimited()}} sets the depth to infinite,
> so if it's run first, then {{XConfiguration#initSubstituteDepth()}} will fail
> because it's testing that the substitution hits a limit. We simply need to
> reset {{initialized}} at the beginning of the test (which
> {{XConfiguration#testSubstituteVarUnlimited()}} actually does already).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
