Comment 1 Gary Gregory 2002-08-27 15:52:33 EDT

Created attachment 1902 [details]
.metadata/.log file

Comment 2 Gary Gregory 2002-08-27 15:53:29 EDT

Now, when I go back and try to use my 2.0 workspace with 2.0 I get a whole 
bunch of:

!ENTRY org.eclipse.ui 4 4 Aug 27, 2002 13:02:41.90
!MESSAGE Unhandled exception caught in event loop.
!ENTRY org.eclipse.ui 4 0 Aug 27, 2002 13:02:41.90
!MESSAGE java.lang.NullPointerException
!STACK 0
java.lang.NullPointerException
	at org.eclipse.ui.internal.WorkbenchWindow$12.shellActivated
(WorkbenchWindow.java:1371)
	at org.eclipse.swt.widgets.TypedListener.handleEvent
(TypedListener.java:157)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:77)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:848)
	at org.eclipse.swt.widgets.Decorations.WM_ACTIVATE
(Decorations.java:1368)
	at org.eclipse.swt.widgets.Shell.WM_ACTIVATE(Shell.java:1086)
	at org.eclipse.swt.widgets.Control.windowProc(Control.java:2663)
	at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1340)
	at org.eclipse.swt.widgets.Display.windowProc(Display.java:1992)
	at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method)
	at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:1602)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1286)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1177)
	at org.eclipse.ui.internal.Workbench.run(Workbench.java:1160)
	at org.eclipse.core.internal.boot.InternalBootLoader.run
(InternalBootLoader.java:775)
	at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
	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.basicRun(Main.java:248)
	at org.eclipse.core.launcher.Main.run(Main.java:698)
	at org.eclipse.core.launcher.Main.main(Main.java:534)

Comment 3 Gary Gregory 2002-08-27 15:57:51 EDT

In case it matters:

(1) I had R2.0 installed in c:\eclipse and I start it with a shortcut:
C:\eclipse\eclipse.exe --vm c:\java\j2sdk1.4.0_01\bin\javaw.exe -
data "C:\Documents and Settings\ggregory.PC1073\My 
Documents\eclipse\workspaces" vmargs -Xmx256m

in the dir: 

"C:\Documents and Settings\ggregory.PC1073\My Documents\eclipse\workspaces"

(2) I renamed c:\eclipse to c:\eclipse-R2.0, which means I no longer had a 
c:\eclipse dir. I created a new shortcut pointing to c:\eclipse-R2.0

(3) I unzipped eclipse-SDK-S20020827-win32.zip in c: which gave me a new 
c:\eclipse whith which my generic short cut points to.

I got the first error mentioned in this report when trying to launch eclipse 
201.

Comment 4 Gary Gregory 2002-08-27 16:02:12 EDT

Shutdown and restart 2.0 give me an error. Did 201 tweaked my 20 workspace?

!SESSION Aug 27, 2002 13:13:53.687 ---------------------------------------------
java.version=1.4.0_01
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86 --vm c:\java\j2sdk1.4.0_01
\bin\javaw.exe -data C:\Documents and Settings\ggregory.PC1073\My 
Documents\eclipse\workspaces vmargs -Xmx256m -install file:C:/eclipse-R2.0/
!ENTRY org.eclipse.core.runtime 4 4 Aug 27, 2002 13:13:53.697
!MESSAGE Unable to read authorization database: C:\Documents and 
Settings\ggregory.PC1073\My Documents\eclipse\workspaces\.metadata\.keyring.
!STACK 0
java.io.StreamCorruptedException: invalid stream header
	at java.io.ObjectInputStream.readStreamHeader
(ObjectInputStream.java:729)
	at java.io.ObjectInputStream.<init>(ObjectInputStream.java:251)
	at org.eclipse.core.internal.runtime.AuthorizationDatabase.load
(AuthorizationDatabase.java:260)
	at org.eclipse.core.internal.runtime.AuthorizationDatabase.load
(AuthorizationDatabase.java:248)
	at org.eclipse.core.internal.runtime.AuthorizationDatabase.<init>
(AuthorizationDatabase.java:73)
	at org.eclipse.core.internal.runtime.InternalPlatform.loadKeyring
(InternalPlatform.java:589)
	at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup
(InternalPlatform.java:581)
	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.internal.boot.InternalBootLoader.startup
(InternalBootLoader.java:909)
	at org.eclipse.core.internal.boot.InternalBootLoader.run
(InternalBootLoader.java:768)
	at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
	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.basicRun(Main.java:248)
	at org.eclipse.core.launcher.Main.run(Main.java:698)
	at org.eclipse.core.launcher.Main.main(Main.java:534)

Comment 5 John Arthorne 2002-08-27 16:42:17 EDT

The first stack trace (InvocationTargetException) is what happens when a new
build of eclipse is unzipped on top of an older build of eclipse.  Is there any
chance that you did that?  The eclipse team has been testing 2.0.1 builds all
week, including many tests with 2.0 and 1.0 workspaces, without seeing this
problem...

The second set of stack traces, with the NullPointerException, you said was when
you reverted back to the 2.0 build?  This could also be a side-effect of not
installing correctly, but I haven't seen a similar case.

The final stack trace, StreamCorruptedException, is expected.  The password file
(.keyring) format was changed for 2.0.1.  Once the file is encoded in the 2.0.1
format, a 2.0 build will not be able to read it.  The work-around is to delete
the .keyring file, and it will be regenerated.

Comment 6 Gary Gregory 2002-08-27 17:48:24 EDT

Well, I have the same routine when I want to use a new e build, which is 
outlined in the entry timestamped "2002-08-27 15:57" below. This "procedure" 
unzips the build but not over an existing build dir. It unzips it to the same 
name that I had before I renamed my 'current' dir, but that means that the dir 
is not there when I unzip. So... I do think there is the possibility that 201 
does not deal with some 20 workspaces just right.

Comment 7 John Arthorne 2002-08-28 11:41:38 EDT

Actually, we have verified that there is a bug.  Sorry for not believing you ;)

The problem is in the reconciler in platform configuration code.  Moving to
update component.

Comment 8 Dejan Glozic 2002-08-28 12:06:25 EDT

Christophe, here is the defect to track the bug you are currently investigating.

Comment 9 Christophe Elek 2002-08-28 12:17:24 EDT

hum, It is a bug, not sure if it is a regression though (I have to check)

The issue is that we attempt to figure out if the platform under has changed by 
checking the platform:base URL. In this is casem the URL hasn't changed as 201 
code replaces 200.

I believe 200 code had this issue where if you replace the code in the same 
directory, we believe it is a new feature and disble it. Thus we disable the 
platfrom for the next startup

As a workaround we can delete the .config directory to force optimistic (enable 
all feature) reconciliation.

Or, installing 2.01 in a different workspace and using -data shoudl work too.

in 2.01
Core is looking at changing boot version so the reconciler will kick off and 
enable 2.0.1 even if installed on top of 2.00 (replacing it)

Comment 10 Christophe Elek 2002-08-30 15:11:49 EDT

fixed in 2.0.1

The issue was the platform we were exepcting (2.0.0) was deleted and we thought
2.0.1 was a 'regular' new feature thus we were 'disabling' it, preventing
eclipse from re-starting

It ended up Startup already found the platform had changed and asked for an
'optimistic' reconciliation (i.e enable all) that Update manager was not honoring.

We now check if Startup wants an optimistic reconciliation first> and it is
does, we reconcile in an optimistic way.

This problem is fixed in 0829 (that was actually the reason why we had a new
build) , and was tested. the scenario explained (2.0.0 is installed in a path
and 'replaced' with 2.0.1 now works)

Close