Bugzilla – Full Text Bug Listing
| Summary: | [discovery][ui] discovery doesn't start on Eclipse 3.4.1 | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Scott Lewis <slewis> |
| Component: | ecf.discovery | Assignee: | Markus Kuppe <bugs.eclipse.org> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | bugs.eclipse.org |
| Version: | 2.1.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 254687 | ||
| Bug Blocks: | |||
| Attachments: | |||
I also tried installing v20081222-1050 on a fresh/clean Eclipse 3.4.1 distribution and I can't get it to discover any jmdns services (e.g. iTunes). So this does seem to be an issue with the v20081222-1050 build and 3.4.1. Note that if I run the Release_2_1 branch in the 3.4.1 debugger I *am* able to get discovered jmdns services. I think it must be something wrong/missing from the v20081222-1050 distribution. Created attachment 121107 [details]
log of exceptions upon start in debugger when using
I've narrowed this down a little further.
In Eclipse 3.4.1
Running in debugger, using Release_2_1 branch of ECF code in workspace.
1) Everything runs/starts OK *iff* the org.eclipse.ecf, and org.eclipse.ecf.identity bundles *from the workspace* are used.
2) If, on the other hand, the org.eclipse.ecf, and org.eclipse.ecf.identity are used from the *platform* (i.e. those that come with Eclipse 3.4.1) the exceptions below are reported to the console upon start of debug session (which seem to be the same as what I was seeing with the first attachment):
3) This problem does not seem to exist with 3.5M*
Created attachment 121114 [details]
patch for Release_2_1 branch to eliminate exceptions on start
This is a patch that eliminates the problem with exceptions on startup (when using platform version of org.eclipse.ecf and org.eclipse.ecf.identity plugins). Unfortunately, this re-introduces an ECFStart class (implements IECFStart) but this does seem to fix the problem.
Markus please take a look at this patch (note: for Release_2_1 branch) and test against Eclipse 3.4.1 using platform versions of o.e.e and o.e.e.i. We'll discuss in conference call Tues 12/23.
FWIW the only (relevant) change between Release_2_1 latest and v20080611-1715 (used for ECF 2.0) is bug #256580. The only other change is bug #233807 and most certainly doesn't matter. Btw. for me it makes no difference if I take o.e.ecf.identity latest or v20080611-1715. Only o.e.ecf matters. While at it, we also wanna keep bug #254684 in mind. (In reply to comment #4) > This is a patch that eliminates the problem with exceptions on startup (when > using platform version of org.eclipse.ecf and org.eclipse.ecf.identity > plugins). Unfortunately, this re-introduces an ECFStart class (implements > IECFStart) but this does seem to fix the problem. It appears as if the only reason ECFStart eliminates the exception, is because it delays discovery provider startup until after resolution of o.e.ecf and o.e.ecf.identity. If the ECFStartup thread would be executed earlier/faster, discovery providers would still fail to load their o.e.ecf/identity class dependencies. The patch has a side effect, that it introduces a time frame where there is a discovery provider bundle resolved but no IDCA service registered with the service registry. This potentially leads to race conditions. I've just noted that 2.1Test/3.4 comes with org.eclipse.ecf_2.0.1.v20081217-1036.jar whereas all other ecf .qualifiers are correctly set to v20081222-1050. 2.1Test/updateSite is completely empty. Created attachment 121136 [details] Bundle-ActivationPolicy: lazy; exclude:="org.eclipse.ecf.core.util" This patch excludes package "org.eclipse.ecf.core.util" of org.eclipse.ecf.identity from lazy activation [1]. Most classes of that package don't require the bundle to be activated anyway (stateless utility classes). Only , except Trace [2] and PlatformHelper [3] require the bundle to be started. Fortunately activation still happens automatically since the Activator [4] is in a different package that is still marked for lazy activation. [1] http://wiki.eclipse.org/Lazy_Start_Bundles [2] org.eclipse.ecf.core.util.Trace [3] org.eclipse.ecf.core.util.PlatformHelper [4] org.eclipse.ecf.internal.core.identity.Activator Created attachment 121137 [details]
mylyn/context/zip
Released patch #121136 [1] to Release_2_1 and HEAD, marking as FIXED [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=121136 (In reply to comment #11) > Released patch #121136 [1] to Release_2_1 and HEAD, marking as FIXED > > [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=121136 > I didn't realize before looking at the patch that this was a change to org.eclipse.ecf.identity. We cannot make changes to org.eclipse.ecf.identity in Release_2_0 stream, as these plugins are distributed with the platform (i.e. 3.4.1). Therefore, for the 2.1 release, we are going to have to do something other than this fix. I suggest that we reintroduce the patch in attachment https://bugs.eclipse.org/bugs/attachment.cgi?id=121114 as I don't know what else we can do in the (very) short term. Raising severity to blocker. I've committed the patch https://bugs.eclipse.org/bugs/attachment.cgi?id=121114 to Release_2_1 stream only, so that I can do a test build and verify that things work correctly in the test build. (In reply to comment #12) > (In reply to comment #11) > > Released patch #121136 [1] to Release_2_1 and HEAD, marking as FIXED > > > > [1] https://bugs.eclipse.org/bugs/attachment.cgi?id=121136 > > > > I didn't realize before looking at the patch that this was a change to > org.eclipse.ecf.identity. We cannot make changes to org.eclipse.ecf.identity > in Release_2_0 stream, as these plugins are distributed with the platform (i.e. > 3.4.1). Typo? This fix isn't intended for Release_2_0 but Release_2_1. > Therefore, for the 2.1 release, we are going to have to do something other than > this fix. I suggest that we reintroduce the patch in attachment > https://bugs.eclipse.org/bugs/attachment.cgi?id=121114 as I don't know what > else we can do in the (very) short term. How are you going to address the race condition mentioned in comment #7? (In reply to comment #13) > Raising severity to blocker. I've committed the patch > https://bugs.eclipse.org/bugs/attachment.cgi?id=121114 to Release_2_1 stream > only, so that I can do a test build and verify that things work correctly in > the test build. Please also run the unit tests for JMDNS and jSLP. I haven't verified that they work with 121114. (In reply to comment #14) > Typo? This fix isn't intended for Release_2_0 but Release_2_1. Yes, I meant Release_2_1. > > > Therefore, for the 2.1 release, we are going to have to do something other than > > this fix. I suggest that we reintroduce the patch in attachment > > https://bugs.eclipse.org/bugs/attachment.cgi?id=121114 as I don't know what > > else we can do in the (very) short term. > > How are you going to address the race condition mentioned in comment #7? > >It appears as if the only reason ECFStart eliminates the exception, is because >it delays discovery provider startup until after resolution of o.e.ecf and >o.e.ecf.identity. If the ECFStartup thread would be executed earlier/faster, >discovery providers would still fail to load their o.e.ecf/identity class >dependencies. Although I'm not certain, I don't *think* that timing/race conditions will be an issue...because: 1) The IECFStart implementations are invoked synchronously (i.e. by putting the following in plugin.xml): <run asynchronous="false" class="org.eclipse.ecf.internal.provider.discovery.ECFStart"> </run> So I don't think races on classload are likely. 2) I think the problem that we've been experiencing may be because the classloading that occurs from within a createExecutableExtension call is somehow different from that done with normal export-package/import-package. Again, I don't know why, but >Please also run the unit tests for JMDNS and jSLP. I haven't verified that they >work with 121114. I've completed the tests against JMDNS...the only failures are WRT the IPv6 test cases (not implemented yet). I'm currently running the jslp test cases now and they so far have failures only in testHashCode and testEquals, but these look like they are Not Yet Implemented. I seem to also get test failures in jslp: testAddServiceListenerIServiceTypeIDIServiceListener testAddServiceListenerIServiceTypeIDIServiceListener testRemoveServiceListenerIServiceListener testRemoveServiceListenerIServiceTypeIDIServiceListener They all seem to have this assertion failure: junit.framework.AssertionFailedError: Test listener didn't receive discovery at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:217) at org.eclipse.ecf.tests.discovery.DiscoveryTest.addListenerRegisterAndWait(DiscoveryTest.java:414) at org.eclipse.ecf.tests.discovery.DiscoveryTest.addServiceListener(DiscoveryTest.java:361) at org.eclipse.ecf.tests.discovery.DiscoveryTest.testRemoveServiceListenerIServiceTypeIDIServiceListener(DiscoveryTest.java:531) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) Is this expected? (In reply to comment #17) > I seem to also get test failures in jslp: > > testAddServiceListenerIServiceTypeIDIServiceListener > testAddServiceListenerIServiceTypeIDIServiceListener > > testRemoveServiceListenerIServiceListener > testRemoveServiceListenerIServiceTypeIDIServiceListener > Is this expected? I guess so. At least they are most certainly separated from this bug/ECFStart and should be tracked in their own bug. .oO(we really need to get the automated test thingy going) (In reply to comment #18) > (In reply to comment #17) > > I seem to also get test failures in jslp: > > > > testAddServiceListenerIServiceTypeIDIServiceListener > > testAddServiceListenerIServiceTypeIDIServiceListener > > > > testRemoveServiceListenerIServiceListener > > testRemoveServiceListenerIServiceTypeIDIServiceListener > > > Is this expected? > > I guess so. At least they are most certainly separated from this bug/ECFStart > and should be tracked in their own bug. .oO(we really need to get the automated > test thingy going) > I agree! I've finished the jslp tests and the above (along with some similar ones in later tests) are the only ones that I see. All have the same "Test Listener didn't receive discovery". I've also done a 2.1 build, and the plugins should soon be available here for test install: http://www.eclipse.org/external/rt/ecf/2.1Test/3.4/updateSite/ Note the version should be: 2.1.0.v20081223-0952 If it's not this version, then the replication hasn't completed. I've got to leave my desk for a while for family business (i.e. putting tire chains on my car to drive in snow) All indications are that the Release_2_1 fix applied from 121114 works. I've tested as described in comments, and built, installed and verified through smoke testing as described by comment #19. Resolving this bug. |
Created attachment 121090 [details] Eclipse 3.4.1 log with ECF v20081222-1050 With Release 2.1 build v20081222-1050 on Eclipse 3.4.1, I get exceptions in log when trying to start/open ECF discovery view and no services are discovered. See the stack traces in the attached log.