Community
Participate
Working Groups
Currently if I have to use a http proxy I've to enter it manually in every workspace. This is not very useable for various reasons. Most programs use the system settings for the proxy (available on all OS). Eclipse should have the possibility to do the same, so an "use system settings" opton should be the default. If the user wants to specify the proxy manually he could choose "specify proxy" and enter the data as ususal.
I agree that this would be ideal. The complication is that each OS does it differently and, to my knowledge, Java doesn't provide an interface to this so we would need to come up with our own API and write a custom native for each platform.
Michael Stather (too many Mikes) do you know the OS APIs required to achieve such a support? Could you prototype such a thing?
Under linux there are standard environment variables like "http_proxy" which are set under all modern distros. Under windows there's an api to access the system settings made through internet explorer or the control panel. For other OS I don't know. If I find out something more I'll post it here.
*** Bug 174261 has been marked as a duplicate of this bug. ***
In order to improve the initial user experience with p2, we would really appreciate if this could be addressed. Could you please schedule this in the 3.4 timeframe? I'm sure we can find help from the community wrt to the APIs on the OS.
+1 Andrew O. should be able to handle the Linux angle. Windows info must be around somewhere. We need a Mac person. the nice thing is that we have a degradation plan (enter it manually) and that plan can be improved to remember values etc. Clearly the first option is to get the settings from the OS. So, is there a clear point at which we need to plug in here? If one was to implement something today, how would it get hooked in?
The best thing IMHO would be to implement this as a system setting, not a workspace one, if possible, as this setting is usually the same on every workspace.
If anyone is really keen, here are some links to the windows APIs you need. first is the InternetQueryOption function which is used to query the proxy info (use option type INTERNET_OPTION_PROXY 38) http://msdn2.microsoft.com/en-us/library/aa385101(VS.85).aspx the buffer should be an INTERNET_PROXY_INFO object, which is described here: http://msdn2.microsoft.com/en-us/library/aa385148(VS.85).aspx You can also get the username and password by querying for: INTERNET_OPTION_PROXY_PASSWORD 44 INTERNET_OPTION_PROXY_USERNAME 43 (buffer should be a null terminated character buffer) Some sample code can be found here: http://msdn2.microsoft.com/en-us/library/aa385384(VS.85).aspx Just curious, if you were to implement this, would you do it the SWT way, with a think wrapper over the WinINet library, or would you implement it all in C?
I wrote a thin layer for the Microsoft WinHttp API (not for all functions!) (http://msdn2.microsoft.com/en-us/library/aa382925(VS.85).aspx). A special java.net.ProxySelector (Java 1.5!) implementation uses this thin layer and with that Java networking can use all of the IE internet settings (also PAC and WPAD, http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol). However, this solution is limited by: - the availability of WinHttp (http://msdn2.microsoft.com/en-us/library/aa384276(VS.85).aspx) - and the use of ProxySelector (Java 1.5) which allows to retrieve a proxy for a specific url! Would that be helpful?
Stefan, I think that could be really useful. However, as a windows user, where would I set the values that are obtained by these calls?
Within Control Panel (System Settings) > Internet Options and than tab ´connections´, button ´lan settings´. All that you can enter here is recognized. I think that you can reach these dialog also from within IE.
You are right I tried that. It sounds that this is what we are after.
I added my ProxySelector implementation for the win32 WinHttp-API with https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2047 I hope that this or even parts of this are helpful.
Created attachment 88543 [details] Win32 ProxySelector implementation This contribution is an implementation of the java.net.ProxySelector (Java 1.5) that uses native code (WinHttp) to retrieve the internet settings/connection settings from IE/Windows. With that users of an RCP application would no longer need to specify the proxy settings manually within RCP. The Java code uses generics. The native code project has been created with the freeware version MS Visual Studio 2008 C++ Express. The original package structure (de.compeople...)has been kept because of simplicity! No regards about changing it. The code is not yet RCP-ready! It is an Eclipse Java project. Feel free to contact me.
CC'ing Grant 'cause he knows stuffs about the Mac and about proxy settings in general. CC'ing Andrew O. because he knows stuffs about Linux. Andrew, Grant, would you be available to provide patches or guidance on the APIs to use to obtain the proxy settings? Thx
Created attachment 90245 [details] example implementation of getting proxy on OSX Attached is a .zip that demonstrates getting proxy info on OSX. Its contents: - Main1.java: stand-alone snippet that does it - swtpatch: swt patch (v3429) that contains the natives, etc. that Main1 uses - two recompiled (PPC) swt libraries with the natives that swtpatch uses This is just a rough example, nothing is currently being freed, etc. Also note that I get different result sets on different OSX versions (I get more information output on OSX 10.3 than on OSX 10.5, so maybe the dictionary location of the info has been moved in newer versions?). Hopefully this at least gives guidance on how this should be doable on OSX.
Created attachment 90246 [details] intended example implementation of getting proxy on OSX sorry, the previous attachment should have been this one
In brief conversations with a few people, it appears that the environment variable http_proxy is relatively standard. gnome-network-preferences sets it, but I don't know any KDE users to ask. Alternatively, there's the gconf key /system/http_proxy. I can keep asking around if that would help. I thought the platform had support for system proxy settings. Am I dreaming?
I'm working on the Linux side of this; developing a Java class that will detect the presence of http_proxy and provide the necessary native implementation to access the Gnome configuration using gconf. This is similar to the approach taken in JRE 5. It seems that KDE also has a proxy setting mechanism; I will investigate this as well. I hope to have a patch completed by 5 March for the env variable and gconf stuff.
Created attachment 91640 [details] Ext. point for proxy providers
Created attachment 91641 [details] Native fragments
I would like to move a discussion between Szymon and me to this list because others are also effected by this topic. I had a look at the proposed IProxyProvider interface (attached here) and I wondered if the interface could not be modeled a little bit closer to the ProxySelector abstract class in jre 1.5. I would propose that Szymon tries to evaluate how much of the jre 1.5 ProxySelector can be ´retained´ with the IProxyProvider so that the existing ProxyService can ´live´ with it.
Created attachment 91739 [details] Linux Implementation First Draft Here is the JNI/Java stuff for a Linux implementation. This is not yet hooked to the APIs that Szymon provided, but the JNI code is pretty much done for Gnome (it will have to be extended a little to get SOCKS, etc, but that will be pretty easy). There are two projects, a Java project and a C Project (I use the CDT for the C project). You should be able to import these two projects and then run the test script that is in the ProxySupport project to see it working. The strategy (when determining the HTTP proxy) to first look at the environment variable, and if it's not set, look at the Gnome config. It will also look at the KDE config, but the native portion of that is not yet implemented. As far as packaging this, I propose that is be done similar to how the localfile stuff is setup in the filesystem package. Essentially the JNI code for all Unixes will be the same, but there will be variations (likely) in the include files and make files. This could be done in a "native" directory just like the filesystem package (in o.e.core.net). In addition, a Java class (which is a merge of my ProxySupport class and Szymon's LinuxProxyProvider class) should be in the o.e.core.net package as well, since it's common to all flavors of Unix (it should be called UnixProxyProvider). The same is probably true for Windows and the Mac since there may be different fragments for different processors and architectures, but the main Java support (the xxxProxyProvider) will be the same. The interface between the xxxProxyProvider and the JNI code is a private matter between those two files.
I agree with this because at some point we will move to JRE 1.5 and if the interfaces are identical (or nearly so), then we can discard our implementation in favor of the Java one. (In reply to comment #22) > I would like to move a discussion between Szymon and me to this list because > others are also effected by this topic. > I had a look at the proposed IProxyProvider interface (attached here) and I > wondered if the interface could not be modeled a little bit closer to the > ProxySelector abstract class in jre 1.5. > I would propose that Szymon tries to evaluate how much of the jre 1.5 > ProxySelector can be ´retained´ with the IProxyProvider so that the existing > ProxyService can ´live´ with it. >
Created attachment 91958 [details] Linux implementation + API changes Here is a working implementation for Linux that tests the http_proxy environment variable and then gets the configuration from gconf (similar to what the JRE 5 does). It does not get the kde settings, but it's not clear how useful that is. I also changed the proxy provider to be more inline with the JRE 5 ProxySelector class. Essentially, I replaced IProxyProvider with AbstractProxyProvider (since we will want to have common code at that level, and we will want it to be extensible). I also changed the since API method in that class to be basically the same are ProxySelector (except that it returns an IProxyData). This provides the UnixProxyProvider and the native code to go with it as well as a test case (but the test needs to be run by hand since it requires manual setting of the proxy config -- this is documented in the test case). I will provide a separate patch that contains the fragments, which include the native library. I have asked a few people about the issue of proxy settings on Linux and they mentioned that we should really get the browser settings. That's a whole other chunk of work, though it will fit into this architecture. Some of the people questioned whether getting the gconf2 (Gnome) settings was worthwhile, and no one seemed to be interested in the KDE settings. My inclination is to not do the KDE stuff unless someone really wants it. I welcome review and comments, and apologize for the whitespace changes in the NetTest code (I'm used to using the automatic formatting a lot - I assume we use the builtin Eclipse style).
Created attachment 91959 [details] Native fragments This replaces the previous native fragments in line with my proposed API. It also includes the built version of the Linux shared library.
This looks good for me. I will try to move my existing win32 (based on MS WinHttp API) solution (see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2047). @Francis: Have you considered to also use the ´connectFailed´ method from ProxySelector? With this method a proxy provider could e.g. reread the native configuration.
(In reply to comment #27) > @Francis: Have you considered to also use the ´connectFailed´ method from > ProxySelector? With this method a proxy provider could e.g. reread the native > configuration. > I thought about this, but did not see the point. I think the point in having it in the Java ProxySelector is to allow user defined ProxySelectors to clean themselves up. But we really don't have any such thing. My implementation just reads the native stuff when select() is called. I don't think we should get too fancy with this stuff.
The Win32 Internet Options offer something called WPAD (http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol). Calling the native method from WinHttp which performs wpad is very expensive - it takes something from 1-2 seconds to perform. Because of this my implementation just calls that method once (of course only if requested) but it would call it a second time when the connectFailed gets called. However, I can retain this buffering and for forcing a ´reread´ a restart would be necessary.
(In reply to comment #29) > The Win32 Internet Options offer something called WPAD > (http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol). Calling the > native method from WinHttp which performs wpad is very expensive - it takes > something from 1-2 seconds to perform. Because of this my implementation just > calls that method once (of course only if requested) but it would call it a > second time when the connectFailed gets called. > However, I can retain this buffering and for forcing a ´reread´ a restart would > be necessary. > I think this would be a good thing for the Unix stuff to hook up to as well. And getting the proxy information from the browser. But all of that is a lot of work. Anyway, on to your point. I would certainly be happy with adding the connectFailed() method, because it would be helpful in your case where you have to cache it. For the Unix implementation, the native stuff just gets the information locally. The only issue though is making sure people will actually call the connectFailed(), because I don't think we control who uses the proxy information. So it might not be that useful.
Created attachment 92027 [details] API moved to internal
Created attachment 92028 [details] Native fragments (ext. point is removed)
Created attachment 92325 [details] core.net + core.ui
Created attachment 92545 [details] Revised core.net (no core.ui) I retested this and there were a couple of problems that I fixed in this patch: 1) The tests were not included (I updated them to reflect the movement of the classes in your patch, also they have whitespace formatting changes) 2) The method setRequiredAuthentication(boolean) was removed from ProxyData; the native code requires this, I added it back. Otherwise everything looks OK. The nativeFragments is unchanged.
Created attachment 93183 [details] core.ui + updated javadocs
The latest patch from Szymon released. He's just told me he meant "core.net" not "core.ui" ;) Leaving open and waiting for the UI part and native fragments
Created attachment 93367 [details] Revised core.net + tests (removed changes previously committed) This includes everything from 92545 except the stuff that was recently committed.
Created attachment 94535 [details] Win32 ProxyProvider The MS-WinHttp API based ProxyProvider
Created attachment 94536 [details] Win32 native fragment for the Win32 ProxyProvider The fragment containing the native code for the Win32 ProxyProvider
Created attachment 94712 [details] Revised Win32 ProxyProvider Win32 ProxyProvider The MS-WinHttp API based ProxyProvider
Created attachment 94713 [details] Revised Win32 native fragment for the Win32 ProxyProvider Win32 native fragment for the Win32 ProxyProvider The fragment containing the native code for the Win32 ProxyProvider
(In reply to comment #41) > Created an attachment (id=94713) [details] > Revised Win32 native fragment for the Win32 ProxyProvider > > Win32 native fragment for the Win32 ProxyProvider > > The fragment containing the native code for the Win32 ProxyProvider > I played with it a bit on Windows XP. I set a proxy configuration script. I run the "loop" test and I noticed that at some point of time 'pacFailed' is set to true. The result is that the service stops returning any proxy. In my console I can see Url: http://www.eclipse.org: host: idproxy42 port: 3128 user: null password: null reqAuth: false Url: https://www.eclipse.org: host: idproxy42 port: 3128 user: null password: null reqAuth: false Url: ftp://www.eclipse.org: Url: socks://www.eclipse.org: Url: http://www.eclipse.org: I noticed that each third call of WinHttp#getProxyForUrl returns false. Moreover I still have the problem with NPE when I use manual proxy settings. When I set only http proxy and leave other proxies not set during the "loop" test, I get NPE. This can be Windows XP issue. java.lang.NullPointerException at java.util.ArrayList.addAll(Unknown Source) at org.eclipse.core.internal.net.proxy.win32.winhttp.WinHttpProxySelector.select(WinHttpProxySelector.java:69) at org.eclipse.core.internal.net.WindowsProxyProvider.getProxyData(WindowsProxyProvider.java:24) at org.eclipse.core.internal.net.AbstractProxyProvider.select(AbstractProxyProvider.java:41) at org.eclipse.core.tests.net.NetTest.proxiesFor(NetTest.java:442) at org.eclipse.core.tests.net.NetTest.testNativeWin32(NetTest.java:436) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:612) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) 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:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:612) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethod(EclipseAppContainer.java:565) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:362) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:612) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
Seems that I attached a wrong patch.
Created attachment 95020 [details] Revised Win32 ProxyProvider (II)
Created attachment 95021 [details] Revised Win32 native fragment for the Win32 ProxyProvider (II)
Created attachment 95030 [details] Linux binary This contains the contents of the "unix" directory in org.eclipse.core.net/natives. Built on Intel PC with Fedora 8.
Created attachment 95187 [details] Revised Win32 ProxyProvider (III) Added more JavaDoc (not enough), joined packages, joined classes, ..
Created attachment 95337 [details] Updated UnixProxyProvider This patch just provides the one class, UnixProxyProvider. This class now gracefully handles the case where the Gnome libraries are not present (this has been tested by renaming one of the shared libraries on the test machine).
Created attachment 95343 [details] Small changes in Revised Win32 ProxyProvider (III)
The fix for the bug introduced new API to work with system proxy settings and win32 fragment. I raised new bugs for the linux fragment and UI in the preferences dialog. New bugs should be raised in case of problems with win32 fragment. Thanks all!
Created attachment 96393 [details] Refactored Win32 ProxyProvider (IV) The refactoring consists of: - changed class names - better self initialization - avoids unnecessary long running native code calls - more attentive to changes in the configuration of the proxies Simply said: better!
I would love to see native KDE support. I can't help you write it (at the moment), but I can point out that Google Chromium implements it, for example. Would you indulge me to re-open this bug for that purpose, or should I open a new bug specifically for it?
