Community
Participate
Working Groups
We now have 2 failing tests in InjectionEventTest. Possibly related to Bug 387579 or when we added new model. Paul, you had done some research into the failures, how far did you get? junit.framework.AssertionFailedError: expected:<1> but was:<0> at org.eclipse.e4.ui.tests.workbench.InjectionEventTest.testEventInjection(InjectionEventTest.java:177) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:657) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:310) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) at org.eclipse.core.launcher.Main.main(Main.java:34) junit.framework.AssertionFailedError: expected:<1> but was:<0> at org.eclipse.e4.ui.tests.workbench.InjectionEventTest.testInjectWildCard(InjectionEventTest.java:248) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:657) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:310) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426) at org.eclipse.core.launcher.Main.main(Main.java:34)
(In reply to Paul Webster from comment #0) > We now have 2 failing tests in InjectionEventTest. Possibly related to Bug > 387579 or when we added new model. > > Paul, you had done some research into the failures, how far did you get? > The tests doing lowish level tests of the OSGi event bus. Both are sending events with listeners flagged by @UIEventTopic. I've stepped completely through the OSGi code. Everything looked fine. I got to the point where UIEventObjectSupplier.UIEventHandlder.handleEvent tries to dispatch the event. There, I'm seeing the following test fail (line 43): if( uiSync == null ) { where uiSync is: @Inject protected UISynchronize uiSync; I still need to explore why uiSync is null - the tests set it up in the context. Interestingly, one of the tests passes, if I run it individually. Finally, I have a hard time believing this has anything to do with bug 387579 or with model changes.
OK. I've got it figured out... Introduced in build I20131119-0800 by bug 387579, not that it is really the fault of that fix... For the tests to PASS, the following events must happen in the following order: 1) the InjectorImpl gets created. This happens the first time ContextInjectionFactory is referenced, as the injector instance is a static field of the class. 2) a default context is supplied to the injector via org.eclipse.e4.core.contexts.ContextInjectionFactory.setDefault(IEclipseContext). This sets the injectors default object supplier. Without it, the injector does not inject context values into OGSi service objects to creates. 3) the UIEventObjectSupplier OSGi service instance gets created. This typically happens as the result of finding the @UIEventTopic annotation during injection. Up until I20131119-0800, the sequence of events occured in the above order. In particular, #2 happened when the first of the now failing tests ran, and #3 happened as part of loading one of the classes in the test. But, the fix for bug 387579 uses the @UIEventTopic annotation in the StackRenderer. Now, #3 happens much sooner (as soon as a test requires the StackRenderer). As a result, the UIEventObjectSupplier does not get injected on creation. The significant consequence of this is that UIEventObjectSupplier is NOTconfigured with a UISynchronized which enables UIEventObjectSupplier to dispatch events to the UI thread. Consequences for the product (Eclipse IDE): None. The IDE already calls ContextInjectionFactory.setDefault(IEclipseContext) early enough that no service object is instantiated but not injected. Fixing the tests. This is more difficult. The tests erroneously assume that they are controlling all the variables, when in fact, they re-using singletons that may already have been instantiated (the ContextInjectionFactory's injector, and the UIEventObjectSupplier OSGi service). Possible fixes: * have the test suite call ContextInjectionFactory.setDefault() before running any tests. Negatives: entrenches the fact that tests are not independent of each other; and, would mean that the individual tests would probably fail if run outside of the test suite. * try to redesign the tests so that they do not rely on the above singletons. Unfortunately, both singletons appear to be deeply entrenched in E4. The best bet might be to see if the tests can destory and re-create the UIEventObjectSupplier. This would require further investigation.
I can't think of anything offhand that would help here. Maybe we need to find the test that causes the failure, and make sure that test does its org.eclipse.e4.core.contexts.ContextInjectionFactory.setDefault(IEclipseContext) early enough so as not to pollute the UIEventObjectSupplier The 2 most common scenarios for this testcase would be 1) run as part of the suite and 2) run individually (which already works). PW
The easy solutions are out. I've tried improving the context that can be registered in InjectionEventTest, and that did nothing. Adding the registration in org.eclipse.e4.ui.tests.workbench.PartRenderingEngineTests.testClientObjectUnsetWhenNotRenderedBug301439() which is the first test to force creation of the UIEventObjectSupplier lead to 32 errors/17 failures, so that's not it. PW
Placing InjectionEventTest first in the test suite (UIAllTests) does remove the failure. I'm just debating with myself whether this is too egregious a hack to employ.
Pushed fix to Gerrit as: https://git.eclipse.org/r/19257
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d795de64da486fff804773b5f3f5c6985eae3062 These failures are the difference in lifecycle between a regular Eclipse4 Application and the many throw-away Applications that the tests spawn. PW
Verified in N20131203-2000.
Verified in build 4.4.0.I20131209-2000
