Bug 479075

Comment 1 Rahul Khimasia 2015-10-21 09:04:30 EDT

I am experiencing this on MS-Windows 7.

Comment 2 Andy Schoenemann 2015-10-27 06:47:29 EDT

Same here with Mars.1 for linux x64!

Comment 3 Mike Meessen 2015-10-28 03:45:43 EDT

Same here: Mars.1 on Windows 7. This is especially frustrating since we're behind a proxy and even opening XML Editors freezes the whole IDE because of unsatisfied network connections!

Definitely a blocker.

Comment 4 Denis Polivanov 2015-11-02 05:04:41 EST

I'd to suggest workaround:
create file "org.eclipse.core.net.prefs" under ${eclipse.install.dir}/configuration/.settings with content:

nonProxiedHosts=localhost

Then restart eclipse.

Comment 5 Rahul Khimasia 2015-11-02 12:52:25 EST

@Denis Polivanov. It works. Thanks.

Comment 6 Mike Meessen 2015-11-03 05:08:35 EST

That didn't solve the problem for me, but I found why:
If you're running eclipse without administrator privileges on Windows, the File mentioned by Denis is not located in the Eclipse installation directory, but here:

c:\Users\[your username]\.eclipse\org.eclipse.platform_4.5.1_129370284_win32_win32_x86_64\configuration\.settings\

Replacing its content with 'nonProxiedHosts=localhost' did the trick.

Comment 7 Svilen D. 2015-11-06 09:38:03 EST

I also get the same error. 
Using Eclipse: Mars SR1, OS: Windows 7.
- I've tried to add nonProxiedHosts setting in ${eclipse.install.dir}/configuration/.settings/org.eclipse.core.net.prefs without success.
- I am using an administrator user and I do not have similar folder: c:\Users\[your username]\.eclipse\org.eclipse.platform_4.5.1_129370284_win32_win32_x86_64\configuration\.settings\

With Luna SR2 I do not have this problem. There I do not have any proxy-related setting in org.eclipse.core.net.prefs file.

Is there some other workaround proposed?

Comment 8 Andrey Loskutov 2015-11-11 09:08:55 EST

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

Comment 9 Andrey Loskutov 2015-11-11 09:10:37 EST

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

Comment 10 Patrik Suzzi 2015-11-11 09:16:28 EST

reporting bug480568#c1 , by Beirti

This does not happen on a brand new workspace but is occurring on all of my existing workspaces. It is also happening for other developers on my team. We haven't changed the proxy settings from their default state.

If anyone can point to the location for the string that it's trying to read, I can hack a workaround together.

Comment 11 Sergey Fukanchik 2015-11-11 15:43:07 EST

creating org.eclipse.core.net.prefs helped. Phew!

Comment 12 Lars Vogel 2015-12-01 06:32:36 EST

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

Comment 13 Brian de Alwis 2015-12-01 11:19:50 EST

So for those experiencing this: what version of Eclipse were you running before upgrading to 4.5.1?

Comment 14 Brian de Alwis 2015-12-01 12:17:56 EST

And for those experiencing this issue:

  * what Eclipse package are you running and where did you get it? (e.g., Mars.1 IDE for JEE Developers from download.eclipse.org)

  * what did your proxy settings look like?


I can't see how null is being passed into StringUtils.split() from ProxyManager#getNonProxiedHosts(). The string is obtained from PreferenceManager#getString(), which should look it up from the ConfigurationScope and if not found then from the DefaultScope:

   // PreferenceManager
   public String getString(String node, String key) {
      return currentScope.node(node).get(key, defaultScope.node(node).get(key, DEFAULT_STRING));
   }

If the currentScope doesn't have <key> ("nonProxiedHosts") it returns the defaultScope's <key>.  So seemingly the default must be null.  But the defaultScope's <key> is configured in the PreferenceInitializer.  So the PreferenceInitializer isn't being run?

Comment 15 Sergey Fukanchik 2015-12-03 14:23:29 EST

I suspect this is because proxy settings come from the system, where non-proxy hosts is empty or something.

Comment 16 Rahul Khimasia 2015-12-08 08:40:35 EST

@Brian de Alwis : 
I am running the Mars.1 IDE for Java developers, 32 bit Windows which I downloaded from https://www.eclipse.org/downloads/. 

I had upgraded from Luna IDE for Java developers, 32 bit Windows. In Luna I had NOT setup any proxy setting, since at that time I was directly connecting to the internet.

Comment 17 Oliver Pfeiffer 2015-12-18 03:07:22 EST

I just wanted to contribute some additional information: I have tried a "nearly fresh" installation based on eclipse-java-mars-1-linux-gtk-x86_64.tar.gz (new Eclipse folder, new workspace, but config files in home directory are old) and confirm that the problem occurs in this constellation. Also the Network Connections panel in Preferences dialog is somewhat wrecked (as seen in the attached screenshot). I have configured one server as both http and https proxy in Ubuntu system settings. 

My system's core data reads:

Ubuntu 14.04 x86_64
Eclipse IDE for Java Developers Mars.1

Comment 18 Oliver Pfeiffer 2015-12-18 03:08:43 EST

Created attachment 258784 [details]
Screenshot of wrecked panel in Network Preferences

Comment 19 Christian Pontesegger 2016-01-18 10:04:34 EST

Happened for me using Eclipse for Jasva Developers, Mars.1 release with a brand new workspace.

Comment 20 Christian Pontesegger 2016-01-18 13:22:52 EST

Brian wrote:
>Although it was a new workspace, the network proxy settings are configuration >scope, not instance scope, and so are located somewhere else in the file system >(viz the osgi.configuration.area property).

>Could you try yet another new workspace and see if the problem occurs for you?  >If so, could you zip up the preferences you have in the configuration area and >send them to me?

It happened during a training where users downloaded eclipse (the zip, not the installer) for the first time on various laptops. We saw the problem happening with their fresh workspaces.

Will check tomorrow if I can get my hands on one of their configurations

Comment 21 Brian de Alwis 2016-01-19 13:04:14 EST

Created attachment 259265 [details]
Runtime debug options

Can you please download this attachment somewhere, and then run your Eclipse with:

   eclipse.exe -consolelog -debug path/to/debug-options

And then attach the console output here?

Comment 22 Marcin Balcer 2016-01-20 06:24:11 EST

Created attachment 259270 [details]
console log with debug options

eclipse version: eclipse-java-mars-1-win32-x86_64
The command used to create the debug:
./eclipse.exe -consolelog -debug debugOptions.txt > debugWithNewWorksapce.log
The debugOptions.txt file contents:
org.eclipse.equinox.preferences/general=true
org.eclipse.equinox.preferences/get=true
org.eclipse.equinox.preferences/set=true
org.eclipse.osgi/debug/bundleTime=true
org.eclipse.osgi/trace/activation=true

I have started eclipse with brand new workspace, then on the preferences page I searched for "proxy" and selected the "Network Connections" page. Then the NPE is logged in the log and the error appears "The currently displayed page contains invalid values".
Please note that after I have modified testNewWorkspace\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.core.net.prefs with the following content:

eclipse.preferences.version=1
nonProxiedHosts=localhost|127.0.0.1
org.eclipse.core.net.hasMigrated=true
proxyData/HTTP/hasAuth=false
proxyData/HTTP/host=<some proxy here>
proxyData/HTTP/port=<some port here?
systemProxiesEnabled=false

The error does no longer appear and I am able to setup proxy settings on  "Network Connections" page.

Comment 23 Brian de Alwis 2016-01-20 10:45:52 EST

Thanks Marcin!  It looks like org.eclipse.core.net is being activated before org.eclipse.equinox.registry, and so its DefaultScope initializer isn't being called.  The DefaultScope initializers are called from a o.e.equinox.preferences' PreferenceServiceRegistryHelper, which is only configured once the IExtensionRegistry is created (viz o.e.eq.preferences' Activator#addingService()).  The PSRH only calls initializers on first-access to DefaultScopes.

The problem can be reproduced by setting org.eclipse.core.net's start level to 1.

Comment 24 Eclipse Genie 2016-01-20 10:57:48 EST

New Gerrit change created: https://git.eclipse.org/r/64781

Comment 25 Szymon Ptaszkiewicz 2016-01-20 11:12:55 EST

(In reply to Brian de Alwis from comment #23)
> Thanks Marcin!  It looks like org.eclipse.core.net is being activated before
> org.eclipse.equinox.registry, and so its DefaultScope initializer isn't
> being called.  The DefaultScope initializers are called from a
> o.e.equinox.preferences' PreferenceServiceRegistryHelper, which is only
> configured once the IExtensionRegistry is created (viz o.e.eq.preferences'
> Activator#addingService()).  The PSRH only calls initializers on
> first-access to DefaultScopes.
> 
> The problem can be reproduced by setting org.eclipse.core.net's start level
> to 1.

The org.eclipse.core.net plugin has not changed for a long time so we need to find the reason why this exception started occurring only recently.

Comment 26 Brian de Alwis 2016-01-20 12:55:07 EST

I agree that understanding what has perturbed the system is important.  We may just have been lucky: core.net doesn't have a dependency on equinox.registry, and from what have observed, core.net and equinox.registry are both marked

Marcin, could you add the following to your debugOptions.txt:

   org.eclipse.osgi/debug/startlevel=true
   org.eclipse.osgi/monitor/lazy=true

and report back?

But the fix is correct: PreferenceManager#getString() is documented to return null, and the calling code in ProxyManager#getNonProxiedHosts() is not handling it:

	public synchronized String[] getNonProxiedHosts() {
		checkMigrated();
		if (nonProxiedHosts == null) {
                        // XXXX getString() may validly return null
			String prop = preferenceManager.getString(PreferenceManager.ROOT, PREF_NON_PROXIED_HOSTS);
			nonProxiedHosts = ProxyType.convertPropertyStringToHosts(prop);
		}

I'm not a committer on Platform/Team, so I can't commit the fix.

Comment 27 Brian de Alwis 2016-01-20 12:57:17 EST

(In reply to Brian de Alwis from comment #26)
> I agree that understanding what has perturbed the system is important.  We
> may just have been lucky: core.net doesn't have a dependency on
> equinox.registry, and from what have observed, core.net and equinox.registry
> are both marked

…as not auto-start and level 4.

In tracing through this, I saw an oddity where the org.eclipse.equinox.security bundle's activator doesn't appear to be properly activated leading to an NPE.  I wonder if there's something fishier going on.

Comment 28 Szymon Ptaszkiewicz 2016-01-20 16:02:50 EST

(In reply to Brian de Alwis from comment #27)
> I wonder if there's something fishier going on.

That's exactly the reason why I don't want to rush with the proposed fix and rather focus on understanding what is happening.

Comment 29 Marcin Balcer 2016-01-20 18:35:34 EST

Created attachment 259288 [details]
console log with lazy debug options

I have run:
eclipse.exe -consolelog -debug debugOptions.txt > debugWithNewWorksapceLazy.log
debugOptions.txt file content:

org.eclipse.equinox.preferences/general=true
org.eclipse.equinox.preferences/get=true
org.eclipse.equinox.preferences/set=true
org.eclipse.osgi/debug/bundleTime=true
org.eclipse.osgi/trace/activation=true
org.eclipse.osgi/debug/startlevel=true
org.eclipse.osgi/monitor/lazy=true

Observation:
I have downlaoded brand new eclipse-java-mars-1-win32-x86_64.zip and the problem does not appear. Next I have installed the same plugins I have in a not-working version and the error does not appear.
I have copied dropins, plugins and features directories from not-working-eclipse to brand new eclipse with all the plugins installed and it still works.
Next I have copied artifacts.xml file - still works.
Next p2 directory - still works.
Next all directories from configuration directory except org.eclipse.osgi - still works.
Next configuration/org.eclipse.osgi - does not work.
The working version has 70 directories in configuration/org.eclipse.osgi while the not-working version has 113.

Comment 30 Brian de Alwis 2016-01-26 15:41:56 EST

(In reply to Brian de Alwis from comment #27)
> In tracing through this, I saw an oddity where the
> org.eclipse.equinox.security bundle's activator doesn't appear to be
> properly activated leading to an NPE.  I wonder if there's something fishier
> going on.

Never mind: my oddity was something else entirely.

From looking at Marcin's log file and from my own healthy instance, here are a few observations:

  * In the log from my runtime, core.net is activated from jsch.core which is in turn lazily activated from the Workbench activating a service or source provider from EGit — so the registry has been long registered
  * In Marcin's log, core.net is activated very early on and it doesn't appear that it was lazily activated.  Unfortunately confirming that requires another debug option (monitor/activation) which I didn't include in the debug-options.txt.

It's as if core.net has been explicitly started and that information has been persisted, so that it is autostarted?

What's interesting is that in my logs core.net actually triggers the activation of equinox.registry as part of calling ProxyManager#initialize() (Activator#start() line 175), but it occurs after the default preferences are normally initialized as part of PreferenceManager#createConfigurationManager() (Activator#start() line 155).


java.lang.Exception: Module is being lazy activated: osgi.identity; osgi.identity="org.eclipse.equinox.registry"; type="osgi.bundle"; version:Version="3.6.0.v20150318-1503"; singleton:="true" [id=189]
[. . . elided . . .]
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at org.eclipse.core.internal.net.ProxyManager.getPluggedInAuthenticator(ProxyManager.java:382)
        at org.eclipse.core.internal.net.ProxyManager.registerAuthenticator(ProxyManager.java:375)
        at org.eclipse.core.internal.net.ProxyManager.initialize(ProxyManager.java:276)
        at org.eclipse.core.internal.net.Activator.start(Activator.java:175)


The 'right' way for org.eclipse.core.net's default initializer is called.

Thread [main] (Suspended (entry into method initializeDefaultPreferences in PreferenceInitializer))	
	PreferenceInitializer.initializeDefaultPreferences() line: 32	
	PreferenceServiceRegistryHelper$1.run() line: 298	
	SafeRunner.run(ISafeRunnable) line: 42	
	PreferenceServiceRegistryHelper.runInitializer(IConfigurationElement) line: 301	
	PreferenceServiceRegistryHelper.applyRuntimeDefaults(String, WeakReference<Object>) line: 131	
	PreferencesService.applyRuntimeDefaults(String, WeakReference<Object>) line: 370	
	DefaultPreferences.applyRuntimeDefaults() line: 222	
	DefaultPreferences.load() line: 276	
	DefaultPreferences(EclipsePreferences).create(EclipsePreferences, String, Object) line: 370	
	DefaultPreferences(EclipsePreferences).internalNode(String, boolean, Object) line: 623	
	DefaultPreferences(EclipsePreferences).node(String) line: 766	
	DefaultScope(AbstractScope).getNode(String) line: 38	
	DefaultScope.getNode(String) line: 74	
	PreferenceManager.<init>(String) line: 49	
	PreferenceManager.createConfigurationManager(String) line: 59	
	Activator.start(BundleContext) line: 155	
        [. . .]
	EquinoxClassLoader(ClassLoader).loadClass(String) line: 357	
	IDEWorkbenchAdvisor.activateProxyService() line: 251	
	IDEWorkbenchAdvisor.postStartup() line: 231	
	Workbench$58.run() line: 2962

Comment 31 Brian de Alwis 2016-01-26 16:23:44 EST

I dug through the framework.info file in Christian's configuration data [*] and it looks like org.eclipse.core.net has been explicitly started but without Bundle.START_TRANSIENT.  org.eclipse.core.net has just AUTO_START whereas other lazily-activated bundles have AUTO_START and USE_ACTIVATION_POLICY.

My guess is that some code is explicitly starting core.net to force the IProxyService to be registered.  Should core.net use Declarative Services to register the service instead?

Comment 32 Brian de Alwis 2016-01-26 16:24:36 EST

Created attachment 259400 [details]
Revised set of debug options

Marcin, could you please try starting over, and run your Eclipse instance with these debug options (added 'org.eclipse.osgi/monitor/activation')?  I'm interested in seeing your log across all of the launches until you see the NPE.  I'm specifically looking for something like:

java.lang.Exception: A persistent start has been called on bundle: org.eclipse.core.net

with a stack trace.  If I'm right, that then that stack should identify which bundle is explicitly starting org.eclipse.core.net.  They should be using Bundle#start(Bundle.START_TRANSIENT).

Comment 33 Marcin Balcer 2016-01-27 08:55:29 EST

Created attachment 259410 [details]
console log for revised set of debug options

./eclipse.exe -consolelog -debug debugOptions3.txt > debugWithNewWorksapce3.log
The debugOptions3.txt file contents:

org.eclipse.equinox.preferences/general=true
org.eclipse.equinox.preferences/get=true
org.eclipse.equinox.preferences/set=true
org.eclipse.osgi/debug/bundleTime=true
org.eclipse.osgi/debug/startlevel=true
org.eclipse.osgi/monitor/lazy=true
org.eclipse.osgi/monitor/activation=true
org.eclipse.osgi/trace/activation=true

Comment 34 Marcin Balcer 2016-01-28 08:02:37 EST

More information to my previous comment:
Some time ago I have downloaded eclipse eclipse-java-mars-1-win32-x86_64.
As far as I remember the error from this ticket was from the very beginning, but I cannot prove that(If I download the zip now it does not have any problems).
Later on to of it I have installed/uninstalled some plugins.
The only way I could install new plugins was to take my laptop from office to home where I am not behind a proxy.
Later I found a workaround to this problem that was to create  testNewWorkspace\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.core.net.prefs with the content from one of my previous posts.
Yet another possible workaround was to create <eclipseHome>\configuration\.settings\org.eclipse.core.net.prefs
For the sake of this bug investigation I have removed the workaround file and copied my eclipse to "C:\TEMP\eclipse-java-mars-1-win32-x86_64 with configurations does not work"
Later I have installed yet few plugins on my original elipse(for example Groovy Compiler 2.4, Groovy-Eclipse, Groovey-Eclipse M2E and Groovy-Eclipse Tests from http://dist.springsource.org/snapshot/GRECLIPSE/e4.5/)
Next I noticed that if I remove the workaround file from my original eclipse the problem does not appear any more.
I do not know if it was the installation of the plugins that changed it or it was something else.
Here is where I run the test (the result is debugWithNewWorksapce3) against the broken copy.
If I install the some of the new plugins on the broken copy I still get an error.



Here are the questions from Brian and my answers:
Q1: Could you try unzipping the installation to a new location and try again?
A1: As I said in my previous comment the problem does not appear if I fetch brand new version from eclipse download page, even if I install all the plugins I currently have.
Q2: And are you installing any additional plugins?  Buildship, for example?
A2: Yes I have plugins install. See also note about groovy plugin above.

Comment 35 Brian de Alwis 2016-01-29 16:06:39 EST

(In reply to Brian de Alwis from comment #31)
> My guess is that some code is explicitly starting core.net to force the
> IProxyService to be registered.  Should core.net use Declarative Services to
> register the service instead?

Found the culprit:

https://github.com/eclipse/buildship/blob/b94340d59942f79c731e9f2ec901b1013ada3918/org.eclipse.buildship.core/src/main/java/org/eclipse/buildship/core/CorePlugin.java#L115

I'll open a bug against Buildship to change to using START_TRANSIENT.

Comment 36 Brian de Alwis 2016-01-29 20:18:46 EST

Szymon, given that Buildship is pretty popular, and the consequences of this bug is baffling to end-users, could we bring this forward to 4.5.2?  The patch is very simple.

Comment 37 Andrey Loskutov 2016-01-30 01:54:08 EST

(In reply to Brian de Alwis from comment #36)
> Szymon, given that Buildship is pretty popular, and the consequences of this
> bug is baffling to end-users, could we bring this forward to 4.5.2?  The
> patch is very simple.

I was not asked but I would give +1 to it.

Comment 38 Szymon Ptaszkiewicz 2016-02-01 10:31:19 EST

The Buildship team decided to fix the cause of the problem for their upcoming Mars.2 contribution (see bug 486870 comment 6) so there is no change required in the Platform code.

Brian, thank you for all your help to narrow the problem down and for finding the root cause!

*** This bug has been marked as a duplicate of bug 486870 ***

Comment 39 Brian de Alwis 2016-02-01 11:27:06 EST

(In reply to Szymon Ptaszkiewicz from comment #38)
> Brian, thank you for all your help to narrow the problem down and for
> finding the root cause!
> 
> *** This bug has been marked as a duplicate of bug 486870 ***

The problem is NOT fixed: Buildship is fixing the symptom, but there are likely thousands of deployed installations of 4.5.1 with org.eclipse.core.net marked as started.  They are the proverbial 'ticking timebomb', regardless of whether they update to 4.5.2.

There are two problems

  1. core.net is dependent on bundle activation order, and will crash should it be started before equinox.registry.  In practice this doesn't look to be such a big deal.

  2. there is a bug in parsing expressions in ProxyType in how it parses preferences that can lead to an NPE.

The fix for #2 in https://git.eclipse.org/r/64781/ is a valid fix regardless of #1.  It also happens to paper over problem #1.

Comment 40 Szymon Ptaszkiewicz 2016-02-01 11:52:27 EST

(In reply to Brian de Alwis from comment #39)
> The problem is NOT fixed: Buildship is fixing the symptom, but there are
> likely thousands of deployed installations of 4.5.1 with
> org.eclipse.core.net marked as started.  They are the proverbial 'ticking
> timebomb', regardless of whether they update to 4.5.2.

As I understand it, the way Buildship started org.eclipse.core.net caused the problem and if it started it properly with START_TRANSIENT, all those installations would not be affected. So the fix in Buildship is for the root cause (i.e. no new symptoms will occur) but even with that fix we will still have a problem with existing symptoms - installations that are having org.eclipse.core.net marked as started. Is this correct?

> There are two problems
> 
>   1. core.net is dependent on bundle activation order, and will crash should
> it be started before equinox.registry.  In practice this doesn't look to be
> such a big deal.
> 
>   2. there is a bug in parsing expressions in ProxyType in how it parses
> preferences that can lead to an NPE.
> 
> The fix for #2 in https://git.eclipse.org/r/64781/ is a valid fix regardless
> of #1.  It also happens to paper over problem #1.

So what are the steps to reproduce problem #2 locally without Buildship?

Comment 41 Brian de Alwis 2016-02-01 12:00:00 EST

(In reply to Szymon Ptaszkiewicz from comment #40)
> Is this correct?

That's right.

> So what are the steps to reproduce problem #2 locally without Buildship?

You can reproduce by setting org.eclipse.core.net's start level to 3 and auto-start.

Comment 42 Szymon Ptaszkiewicz 2016-02-02 09:01:18 EST

Brian, thanks for confirmation.

Since we are after Mars.2 RC2 there is a PMC approval needed for it in case we wanted to fix it there.

Dani, please see comments starting from comment 35 and advise if the proposed change (even if not the cause of the problem) qualifies for RC3.

Comment 43 Dani Megert 2016-02-02 09:11:55 EST

(In reply to Szymon Ptaszkiewicz from comment #42)
> Brian, thanks for confirmation.
> 
> Since we are after Mars.2 RC2 there is a PMC approval needed for it in case
> we wanted to fix it there.
> 
> Dani, please see comments starting from comment 35 and advise if the
> proposed change (even if not the cause of the problem) qualifies for RC3.

This is a strange request. The bug is closed and the proposed change has a -2.

Is this a regression?

Comment 44 Szymon Ptaszkiewicz 2016-02-02 09:44:36 EST

(In reply to Dani Megert from comment #43)
> (In reply to Szymon Ptaszkiewicz from comment #42)
> > Brian, thanks for confirmation.
> > 
> > Since we are after Mars.2 RC2 there is a PMC approval needed for it in case
> > we wanted to fix it there.
> > 
> > Dani, please see comments starting from comment 35 and advise if the
> > proposed change (even if not the cause of the problem) qualifies for RC3.
> 
> This is a strange request. The bug is closed and the proposed change has a
> -2.
> 
> Is this a regression?

Not for SDK itself but for some EPP users yes. The exception from comment 0 can happen only for Mars.1 users who tried Buildship. Buildship was added to Simultaneous Release in Mars.1. The code in Buildship does

Platform.getBundle("org.eclipse.core.net").start();

instead of

Platform.getBundle("org.eclipse.core.net").start(Bundle.START_TRANSIENT);

The bug in Buildship is fixed via bug 486870 and will be contributed to Mars.2 so it will not happen again for new installations. But according to what Brian says in comment 39 and later, the existing installations even after update to Mars.2 will still have information that org.eclipse.core.net should be started early so users who were affected by the exception from comment 0 will keep seeing it even in Mars.2 but would not get this problem if they started fresh with Mars.2.

The change proposed by Brian "papers over" the exception from comment 0 so that it no longer bothers users, but it does not fix broken installations.

Papering over this particular NPE means that org.eclipse.core.internal.net.ProxyManager.nonProxiedHosts may be initialized with a wrong value and will never be recomputed later thus breaking proxy users. To me this is sufficient that the proposed approach is not right, but since we are running out of time for Mars.2 I asked PMC to advise of other possible solutions.

Comment 45 Dani Megert 2016-02-02 09:48:14 EST

(In reply to Szymon Ptaszkiewicz from comment #44)
> not right, but since we are running out of time for Mars.2 I asked PMC to
> advise of other possible solutions.

I suggest to leave things as is.

Comment 46 Brian de Alwis 2016-02-02 12:32:26 EST

(In reply to Dani Megert from comment #45)
> (In reply to Szymon Ptaszkiewicz from comment #44)
> > not right, but since we are running out of time for Mars.2 I asked PMC to
> > advise of other possible solutions.
> 
> I suggest to leave things as is.

With 10 votes on this bug, 3 duplicate reports, UI freezes (comment 3), and a hard-to-discover workaround (comment 4 and comment 6), I strongly recommend that this bug should be fixed.  And I disagree with Szymon's characterization of this fix.

This patch fixes one method to handle a null preference value, a legal value, in a manner that is consistent with the rest of the code in core.net.  There are two other alternatives (at the end).

The root cause of this bug is that PreferenceManager#getString() is documented to return null, but ProxyManager#getNonProxiedHosts() / ProxyType#convertPropertyStringToHosts() do not handle it.  The other methods that use #getString() do handle null (e.g., ProxyType#createProxyData()), so getNonProxiedHosts() is the anomaly.

This situation arises as the core.net's default preference initializer is not being run, and so core.net's DefaultScope is not initialized.  core.net's PreferenceManager#getXXX returns its default-default values instead (respectively -1, false, and null for int, boolean, and string).  Let me emphasize that *none* of the proxy preference defaults are initialized.  But all other uses of proxy preferences properly handle the default-default values.

This patch does not change how or what values are computed: if the user explicitly sets a value, then that value will be returned.  This patch only changes what happens if there are no explicit values set AND the defaults have not been initialized.  Hence the workarounds in comment 4 and comment 6: they set an explicit value for nonProxiedHosts.

We're seeing this as Buildship causes core.net to be explicitly started and so subsequent launches causes core.net to be activated before equinox.registry, and equinox.registry only runs preference initializers for subsequently activated bundles.  So if core.net is started before equinox.registry, then core.net's default preference initializers are *never* run.  So the values are never recomputed, and the proxy users continue to be broken.

That core.net is usually activated after equinox.registry seems to be coincidence rather than by design.  But any headless service or early-start service that activates core.net to access the IProxyService could trigger this bug.


There is another alternative.  One fix would be to change the visibility of PreferenceInitializer.DEFAULT_PREF_NON_PROXIED_HOSTS and change ProxyManager#getNonProxiedHosts() to something like:

	String prop = preferenceManager.getString(PreferenceManager.ROOT, PREF_NON_PROXIED_HOSTS);
	if(prop == null) {
		prop = PreferenceInitializer.DEFAULT_PREF_NON_PROXIED_HOSTS;
	}
	nonProxiedHosts = ProxyType.convertPropertyStringToHosts(prop);

But we should really then do this systematically across all the proxy preferences.

Comment 47 Thomas Watson 2016-02-03 11:19:48 EST

I have not looked at the bug fix in particular, but I will say that if the equinox.registry is an important thing for core.net to function properly then core.net likely should ensure the registry is activated when core.net is activated.  For example, by getting the registry service in activation which would cause the registry to lazily activate.

Comment 48 Brian de Alwis 2016-02-03 12:24:44 EST

Unfortunately obtaining the registry won't do the right thing if core.net is activated at a different start level than equinox.registry.

Comment 49 Thomas Watson 2016-02-04 13:21:31 EST

(In reply to Brian de Alwis from comment #48)
> Unfortunately obtaining the registry won't do the right thing if core.net is
> activated at a different start level than equinox.registry.

That has to be considered a configuration error.  I'm sure an enormous amount of things in the eclipse platform would fail if the registry is at a higher start level.

Comment 50 Andreas Sewe 2016-02-14 06:20:42 EST

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

Comment 51 Brian de Alwis 2016-02-27 21:56:32 EST

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