Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 94859

Summary: bundle data discarded on every startup if install != user.dir
Product: [Eclipse Project] Platform Reporter: John Arthorne <john.arthorne>
Component: RuntimeAssignee: Rafael Chaves <eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: tjwatson
Version: 3.1   
Target Milestone: 3.1 M7   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
patch for org.eclipse.osgi none

Description John Arthorne CLA 2005-05-11 17:50:45 EDT 
Build: I20050509-2010, running with all core+tests from HEAD.

TestBug93473 consistently fails for me on Linux.  Here is the stack trace:

junit.framework.AssertionFailedError: 1.0 expected:<2> but was:<3>
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.failNotEquals(Assert.java:282)
	at junit.framework.Assert.assertEquals(Assert.java:64)
	at junit.framework.Assert.assertEquals(Assert.java:162)
	at
org.eclipse.core.tests.resources.session.TestBug93473.test2ndSession(TestBug93473.java:78)
	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:324)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	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:118)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:474)
	at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342)
	at
org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:57)
	at
org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:24)
	at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:230)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:345)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:158)
	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:324)
	at org.eclipse.core.launcher.Main.invokeFramework(Main.java:328)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:272)
	at org.eclipse.core.launcher.Main.run(Main.java:974)
	at org.eclipse.core.launcher.Main.main(Main.java:950)
Comment 1 Rafael Chaves CLA 2005-05-11 23:19:32 EDT 
Original summary: "Content type session test failure in HEAD"

Turns out that the test failed because it was sensitive to the platform state
stamp (Platform#getStateStamp()). It took me hours to understand why in John's
setup plug-ins were being reinstalled every startup (modifying the state stamp
accross sessions), and not only once. The reason is that the current user dir
was affecting the way we compute plug-in install relative locations.

The scoop:
- the test failing here is sensitive to the platform state stamp changing. It
should not change, but in the case of John's setup it was;
- the stamp was changing because plug-ins were being discarded/reinstalled;
- the reason: we store plug-in install locations as paths relative to the instal
path. But when reading the bundle data in a second startup, the install location 
was not set yet (it was null);
- new File(null, relativePath) creates a path relative to the user.dir. It so
happens that for many people, the user.dir will be the Eclipse install dir, so
this would not cause problems;
- in your case, the user.dir is the parent directory for the Eclipse install, so
you must have been having all plug-ins uninstalled/reinstalled during every startup!

The interesting thing is that this seems to be the happening since mid-March
(when the first support for relative bundle install paths was added - see bug
88078).

Fix is to make sure we initialize the installPath as soon as possible
(EclipseAdaptor#initialize()). Will attach a patch that does that.
Comment 2 Rafael Chaves CLA 2005-05-11 23:25:02 EDT 
Created attachment 21024 [details]
patch for org.eclipse.osgi

Tom, can you take a look? The changes are very minor.
Comment 3 Jeff McAffer CLA 2005-05-12 09:30:52 EDT 
update the patch to test if the location is null
Comment 4 Thomas Watson CLA 2005-05-12 09:38:44 EDT 
Fix has been released to HEAD.  I added a null check suggested in comment 3.
Comment 5 Rafael Chaves CLA 2005-05-12 10:56:19 EDT 
Shouldn't we fail instead of ignoring the install location? We would not go much
farther anyway.
Comment 6 Thomas Watson CLA 2005-05-12 11:10:56 EDT 
maybe.  The goal was to change the behavior as little as possible.  Before the 
patch we would not fail with an NPE.  We can consider changing this, but leave 
for post M7 ...