Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #227252 +++ The fix for Bug #227252 introduced a serious regression - org.eclipse.help.internal.base.remote.HttpsUtility.getHttpsInputStream(String, String, String, String, String) contains the line System.setProperty( "java.protocol.handler.pkgs" , "javax.net.ssl" ); //$NON-NLS-1$ //$NON-NLS-2$ This has the side effect of changing the protocol handler throughout the entire application, not just Eclipse, which can cause this kind of an exception ( this was on Solaris ) when running any code that causes the java protocol handler to be invoked. java.lang.RuntimeException: java.net.MalformedURLException: unknown protocol: https
Comments copied from Bug #227252 Thomas Watson 2010-11-02 10:00:50 EDT Can someone explain why you need to set the system property: System.setProperty( "java.protocol.handler.pkgs" , "javax.net.ssl" ); At a minimum I think you need to check for an existing "java.protocol.handler.pkgs" property and append "|javax.net.ssl" if it already exists. Thomas Watson 2010-11-02 10:29:27 EDT Setting java.protocol.handler.pkgs=javax.net.ssl implies that we expect the class javax.net.ssl.https.Handler to exist for handling https protocols. What version of java does this exist? Jim Perry 2010-11-02 16:41:40 EDT Removing the line: System.setProperty( "java.protocol.handler.pkgs" , "javax.net.ssl" ); Causes remote help to still work (on Windows). So at minimum, the line may not be required. I will investigate Linux and Solaris to verify that the handler package is supported there as well.
The Javadoc for URL contains some information about when java.protocol.handler.pkgs is used. http://download.oracle.com/javase/1.5.0/docs/api/java/net/URL.html#URL%28java.lang.String,%20java.lang.String,%20int,%20java.lang.String%29 Looking at the sequence for resolving protocols it appears that even if you specify a nonexistent package name for java.protocol.handler.pkgs some JREs may still be able to resolve the https protocol. On the other hand it's possible that on some JREs changing the value of java.protocol.handler.pkgs could cause https and other protocols to fail. That is what appears to be happening on Solaris. We need to test this on all of the major Platform/JRE combinations Win32 ( Both Oracle JRE and IBM JRE ) Linux ( Both Oracle JRE and IBM JRE ) Solaris Mac OS Not setting java.protocol.handler.pkgs is going to be much safer since it will not impact any other code which uses the URL class. We next need to test the remote help code to see if all of those JREs will handle https out of the box. If not using a URLStreamHandler in the constructor of URL would be preferable to setting a system property.
Created attachment 183329 [details] Patch with the System.setProperty() line removed HTTPS remote help still works without the System.setProperty() line. The property already has the HTTPS support we need. The Patch has all occurrences of this line removed from HttpsUtility.
Patch committed to HEAD, Fixed
Just FYI, Remote help works on Solaris with the System.setProperty() line in the code.
