Comment 1 John Arthorne 2010-07-26 12:57:46 EDT

Bug 287720 looks a little bit like this. You said on the list this only fails with Sun/Oracle Java 6 Update 20 or 21? Did you run successfully with other VM versions? Is this a problem that just started happening in a recent Eclipse 4.0 build or it failed in every 4.0 build you have tried?

Comment 2 Boris Bokowski 2010-07-26 13:12:15 EDT

The problem is that the proxy stuff asks for an active workbench window before it is created by our startup code.

Remy, should we be moving the following:
   "initializationDone = true;"
from Workbench.java line 1338 to some other place?

Comment 3 Boris Bokowski 2010-07-26 13:12:45 EDT

Kai, can you try a new workspace? Does it happen with a new workspace as well?

Comment 4 Remy Suen 2010-07-26 13:23:19 EDT

(In reply to comment #2)
> Remy, should we be moving the following:
>    "initializationDone = true;"
> from Workbench.java line 1338 to some other place?

It's probably "safe" but postStartup() spec's that the workbench windows are expected to be up and running when the method has been called. Getting a 'null' would not really make sense.

Comment 5 Boris Bokowski 2010-07-26 13:34:16 EDT

(In reply to comment #4)
> It's probably "safe" but postStartup() spec's that the workbench windows are
> expected to be up and running when the method has been called. Getting a 'null'
> would not really make sense.

Well then it looks like we're not honoring that contract, since the workbench windows are not up and running when the code asks for the active workbench window:

at org.eclipse.ui.internal.Workbench.createWorkbenchWindow(Workbench.java:1149) 
at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(Workbench.java:1123) 
at org.eclipse.ui.internal.progress.ProgressManagerUtil.getNonModalShell(ProgressManagerUtil.java:353)

Comment 6 Remy Suen 2010-07-26 14:18:54 EDT

(In reply to comment #5)
> (In reply to comment #4)
> > It's probably "safe" but postStartup() spec's that the workbench windows are
> > expected to be up and running when the method has been called. Getting a 'null'
> > would not really make sense.
> 
> Well then it looks like we're not honoring that contract

That's correct. From a preliminary investigation, this seems to be because we require some services from the application that are not available at that time since we bring up the 3.x workbench first before bringing up the e4 workbench.

Comment 7 Boris Bokowski 2010-07-26 14:31:59 EDT

I put a breakpoint in the WorkbenchWindow constructor to see where we instantiate it on startup, and it looks like it's not very well-defined because it happens in response to an event handler that triggers from a random place (during createGUI).

I don't see how we can fix this problem other than by something that has only a local effect in ProgressManagerUtil (e.g. return null for the parent shell).

Comment 8 Remy Suen 2010-07-26 14:41:51 EDT

Created attachment 175257 [details]
ProgressManagerUtil patch v1

(In reply to comment #7)
> I don't see how we can fix this problem other than by something that has only a
> local effect in ProgressManagerUtil (e.g. return null for the parent shell).

Agreed. It is too risky to try to fix the startup code at this point.

Comment 9 Kai Toedter 2010-07-26 15:02:04 EDT

@Boris, it is the same with a brand new workspace
@John, it happens with all Eclipse 4.0 Early Adopter SDKs I have tested so far. JDK 6 Update 20 and 21 are the only JDKs I currently have on my machine. 

The same happens with RC3, the log is almost the same.

I am wondering why I seem to be the only one who experiences this behavior...

Comment 10 Boris Bokowski 2010-07-26 15:45:48 EDT

(In reply to comment #9)
> I am wondering why I seem to be the only one who experiences this behavior...

You seem to have some kind of proxy setting that leads to a prompt for a password on startup. Do you get a password prompt when you start Eclipse 3.6?

Szymon, can you tell (by looking at the stack trace) how Kai's configuration differs from ours? Is there a workaround that would avoid the failing password prompt?

Comment 11 Kai Toedter 2010-07-26 15:58:51 EDT

 @Boris, but currently I am using no proxy settings (in IE and Firefox) since I am not behind a firewall. Which proxy settings is a fresh Eclipse 4.0 SDK picking up then?

Comment 12 Boris Bokowski 2010-07-27 12:53:21 EDT

Kai,

Could you please try the following:

1. Open a 3.6 version of Eclipse (one that has no startup problems)
2. Open the preferences dialog and go to General>Security>Secure Storage
3. On the Contents tab near the bottom, note the location of the Equinox secure storage. It should be: <user home>/.eclipse/org.eclipse.equinox.security/secure_storage
4. Quit Eclipse 3.6
5. Rename the secure storage file or move it to another location
6. Start Eclipse 4.0

When you're done trying out Eclipse 4.0, you may want to put the secure storage file back where it was so that you have your passwords again when in 3.6.

Sorry for the inconvenience, but unfortunately we've discovered this too late for the release and will have to document this as a workaround. We'll fix it in the 4.1 stream as soon as possible, after the release.

Comment 13 Oleg Besedin 2010-07-27 14:22:54 EDT

Boris and I were able to reproduce this.
 
=> 1. Identifying the problem

Start Eclipse 4.0 using a new workspace. If Eclipse instance shuts down after displaying the workspace chooser dialog, check the log file (workspace/.metadata/.log). If it contains a line like:

  An error occurred while automatically activating bundle org.eclipse.core.net

then you probably hitting this bug.

=> 2. What's happening?

The problem is triggered by setting proxy authentication information.

The information is written in the secure storage; on Eclipse startup proxy information is needed very early, way before normal workbench services are available. When proxy processing tries to retrieve the encrypted data, the Dysplay#syncExec() call triggers access to non-initialized Workbench which does not go well.

=> 3. Is there a workaround?

The easiest thing to do is to delete or rename the secure storage file. 

=> 3a. If you have an Eclipse 3.x, it can be done via its Preferences dialog:

  Preferences -> General -> Security -> Secure Storage; "Contents" tab.

The secure storage can be deleted by pressing "Delete" button on that page; alternatively, see the "Storage location" field and use the operating system to rename the secure storage file.

=> 3b. The default location of the secure storage is calculated using Java "user.home" variable: @user.home + ".eclipse\org.eclipse.equinox.security\secure_storage". For instance, on WinXP:

  C:\Documents and Settings\<user_name>\.eclipse\org.eclipse.equinox.security\secure_storage

The operating system than can be used to rename the "secure_storage" file.

Comment 14 Oleg Besedin 2010-07-27 14:25:01 EDT

Created attachment 175343 [details]
Relevant portion of the call stack

Comment 15 Kai Toedter 2010-07-28 00:54:52 EDT

The workaround (I just renamed the secure_storage) works well! Thanks a lot!

Comment 16 Oleg Besedin 2010-07-30 11:49:59 EDT

This boils down to the problem in the workbench lifecycle: the workbench reports being "ready" while it is not. Another, more generic, consequence is the interval in the startup when we have nothing at all on the screen: the splash screen is taken down, but renderers haven't yet produced any actual UI elements.

In more details:

In 3.x the Workbench#init() method is expected to restore or open at least one window. However, in e4 the WorkbenchWindow is created much later, in fact, as a response to #showTab() call on some random tab. Also, the state of the Workbench after the #init() call does not allow WorkbenchWindow to be created as elements are missed from the context (filled later by renderers).

The sequence is:

 Workbench#runUI()
   createSplashWrapper()  <= splash screen is up
   init()                 <= UI is initialized and expected to appear on screen
   Platform.endSplash();  <= splash screen is down
   advisor.postStartup(); <= this is there this specific error happen

The lifecycle needs to provide initial rendering in the Workbench#init(). Right now, the supposedly initialized workbench misses critical pieces that are filled in by renderers. (IPresentationEngine and IResourceUtilities are the two items I immediately tripped over; there are more.)

Comment 17 Oleg Besedin 2010-10-12 15:34:16 EDT

Eric, did you have a chance to look into this?

Comment 18 Eric Moffatt 2010-10-12 16:07:32 EDT

How about we try to turn this on its head. Rather than trying to maintain the existing startup *code*, why not see if we can start up like an e4 RCP app and then after the rendering is done to issue the events / calls in the correct order.

In this scenario we would:

- Show the splash

- Load the model (as many of the compatibility artifacts as we can should be created in synch with the rendering cycle (i.e. WorkbenchWindow, WorkbenchPart...).

- Hide the splash

- Once the model is loaded we would 'fake' the current startup cycle, making any necessary calls / sending any necessary events...

While i recognize that this may introduce some regressions we'll end up in a much better position. The 3.x startup code is *too complex* and needs to be replaced...

What issues (aside from the ones on this defect) are we likely to encounter with this approach ??

Comment 19 Paul Webster 2010-10-14 09:08:55 EDT

Just notes from last time.  We were only able to get the SDK up if we allowed the Workbench, WorkbenchWindow, and Perspective to initialize the model.  When we tried the other way (building the legacy objects around a model) we weren't able to get past the activators of JDT UI (and parts of debug).

On top of that, it was not RCP (3.x) compatible at all, since the RCP lifecycle has a number of programmatic hooks that provide in effect large parts of the model for that application.

PW

Comment 20 Eric Moffatt 2010-10-15 10:05:34 EDT

Created attachment 180958 [details]
Patch to control whether to use delta & to do a 'direct' load/save


The idea is to be able to save the current model state and reload it on startup. Then we can address the issues of trying to instantiate the compatibility elements as part of the rendering stage.

Comment 21 Oleg Besedin 2010-12-13 10:54:43 EST

*** Bug 332447 has been marked as a duplicate of this bug. ***

Comment 22 Bill Blalock 2011-05-13 16:12:23 EDT

This is my first time with 4.1 (eclipse-SDK-4.1M7-win32.zip).

I believe I have also run into this problem with the current release for 4.1M7.  The "caused by" in my log file is the same as the initial report.

The work around (renaming secure storage file) did work, I am now seeing the workbench.

My secure storeage file was created when I started to use GIT.  Deleting it is not an option for me.

Regards
Bill Blalock

Comment 23 Remy Suen 2011-05-16 09:21:29 EDT

(In reply to comment #8)
> Created attachment 175257 [details]
> ProgressManagerUtil patch v1

I've released this patch so that ProgressManagerUtil won't inadvertently try to create workbench windows.

The bug of postStartup() being called at an inopportune time is still there.

Comment 24 Remy Suen 2011-05-19 10:59:29 EDT

To reproduce the problem, I had Eclipse create the secure_storage file for me and then also went to 'General > Network Connections' and added some garbage to the HTTPS setting asking it to require authentication.

I then proceeded to the 'General > Security > Secure Storage' preference page and unchecked the 'Windows Integration' checkbox in the 'Password' tab.

Unfortunately, the workaround I committed no longer works because it seems Equinox has changed the way they get a modal shell. Instead of going to the ProgressManagerUtil they have changed the code to ask the workbench for its active workbench window directly, walking through the same code path that the workaround was trying to get it to avoid.

org.eclipse.e4.core.di.InjectionException: Unable to process "WorkbenchWindow.engine": no actual value was found for the argument "IPresentationEngine".
	at org.eclipse.e4.core.internal.di.InjectorImpl.reportUnresolvedArgument(InjectorImpl.java:377)
	at org.eclipse.e4.core.internal.di.InjectorImpl.resolveRequestorArgs(InjectorImpl.java:372)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:97)
	at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:78)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.inject(ContextInjectionFactory.java:72)
	at org.eclipse.ui.internal.Workbench.createWorkbenchWindow(Workbench.java:1172)
	at org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow(Workbench.java:1146)
	at org.eclipse.equinox.internal.security.ui.storage.StorageUtils.getShell(StorageUtils.java:27)
	at org.eclipse.equinox.internal.security.ui.storage.StorageLoginDialog.<init>(StorageLoginDialog.java:58)
	at org.eclipse.equinox.internal.security.ui.storage.DefaultPasswordProvider.getPassword(DefaultPasswordProvider.java:44)
	at org.eclipse.equinox.internal.security.storage.PasswordProviderModuleExt.getPassword(PasswordProviderModuleExt.java:35)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getModulePassword(SecurePreferencesRoot.java:259)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesRoot.getPassword(SecurePreferencesRoot.java:224)
	at org.eclipse.equinox.internal.security.storage.SecurePreferences.get(SecurePreferences.java:262)
	at org.eclipse.equinox.internal.security.storage.SecurePreferencesWrapper.get(SecurePreferencesWrapper.java:106)
	at org.eclipse.core.internal.net.ProxyType.loadProxyAuth(ProxyType.java:537)
	at org.eclipse.core.internal.net.ProxyType.createProxyData(ProxyType.java:138)
	at org.eclipse.core.internal.net.ProxyType.getProxyData(ProxyType.java:127)
	at org.eclipse.core.internal.net.PreferenceManager.migrateInstanceScopePreferences(PreferenceManager.java:292)
	at org.eclipse.core.internal.net.PreferenceManager.migrate(PreferenceManager.java:260)
	at org.eclipse.core.internal.net.ProxyManager.checkMigrated(ProxyManager.java:404)
	at org.eclipse.core.internal.net.ProxyManager.initialize(ProxyManager.java:269)
	at org.eclipse.core.internal.net.Activator.start(Activator.java:181)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:299)
	at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:440)
	at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:268)
	at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:107)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:462)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:473)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Unknown Source)
	at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.activateProxyService(IDEWorkbenchAdvisor.java:290)

Comment 25 Remy Suen 2011-05-19 11:17:00 EDT

Created attachment 196126 [details]
Workbench patch v2

Change Workbench's getActiveWorkbenchWindow() method to not try to create a workbench window if the rendering engine isn't available.

Comment 26 Remy Suen 2011-05-19 11:17:52 EDT

(In reply to comment #25)
> Created attachment 196126 [details]
> Workbench patch v2

Patch released to CVS HEAD. Problem goes away in my inner. Will try again with tonight's build tomorrow.

Comment 27 Remy Suen 2011-05-20 07:53:38 EDT

(In reply to comment #26)
> Patch released to CVS HEAD. Problem goes away in my inner. Will try again with
> tonight's build tomorrow.

Looks okay now with I20110519-2200. The secure storage prompt will come up properly.

Comment 28 Remy Suen 2011-05-25 13:04:46 EDT

One possible way to get code to run after the application is up and running is to implement the StartupMonitor interface and register it as a service with OSGi. Its applicationRunning() method is the way we know that the renderer has completed its rendering process so we could put the postStartup() call in there.

Comment 29 Eric Moffatt 2011-07-21 14:05:06 EDT

*** Bug 320021 has been marked as a duplicate of this bug. ***

Comment 30 Dean Roberts 2011-07-21 14:08:26 EDT

Another test case to demonstrate this issue.

Add the following line of code:

PlatformUI.getWorkbench().getActiveWorkbenchWindow();

To PerspectiveRegistry.postConstruct() method.

Launch a runtime workbench and you will get an InjectionException caused by a
NullPointerException in StandardTrim.createStatusLine().  The WorkbenchWindow
retrieved from the context is null.

Comment 31 Kris Slowinski 2014-07-09 10:28:08 EDT

Created attachment 244929 [details]
Eclipse project to reproduce the InjectionException

I am trying to migrate Eclipse 3.x application to Eclipse 4.x and currently I experiment with Eclipse 4.4. I have followed tutorials that present the migration and currently I am trying to use the Compatibility Layer to run the application with Eclipse 4.4. The attached project represents the minimal example that causes the exception in my application and is similar to the exception encountered in this bug. In my situation it is triggered when invoking openWorkbenchWindow(PERSPECTIVE_ID, null) of IWorkbench: org.eclipse.e4.core.di.InjectionException: Unable to process "PartServiceImpl.engine": no actual value was found for the argument "IPresentationEngine".

Can it be caused by missing dependencies, or should the window opening be modified. Would be great to know if this is an actual bug or if the code should be  changed.

Comment 32 Paul Webster 2014-07-09 12:33:10 EDT

(In reply to Kris Slowinski from comment #31)
> Created attachment 244929 [details]
> Eclipse project to reproduce the InjectionException

This is a different problem.  Could you please open a new bug and we can discuss there.

PW

Comment 33 Kris Slowinski 2014-07-10 04:06:58 EDT

I opened a new bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439319

Comment 34 Paul Webster 2014-07-17 09:38:15 EDT

This works for me in Luna.  Please re-open if you find it reproducible there and we'll get to the bottom of it.

PW

Comment 35 Sébastien Gandon 2014-11-06 09:10:47 EST

The contract for the 
advisor.postStartup() call back is supposed to have a workbench window open and restored which is not the case as of today Luna's release.
because when calling : PlatformUI.getWorkbench().getActiveWorkbenchWindow(), I'll get a null value from org.eclipse.ui.internal.Workbench.getActiveWorkbenchWindow() : 

// rendering engine not available, can't make workbench windows, see bug
// 320932
if (e4Context.get(IPresentationEngine.class) == null) {
   return null;
}


Shall I reopen this bug or create a new one for this specific issue ?