Community
Participate
Working Groups
Build Identifier: 20090920-1017 The Edit Proxy Entry dialog should have an Check button and a setting for a web page (default: eclipse.org) which Eclipse would try to get on pressing the button. A similar feature has Apache Directory Studio (see screen shot). Reproducible: Always
Created attachment 155480 [details] Apache Directory Studio's check connection dialog
Team component only provides proxy settings which are consumed by various clients like JRE HTTP client and or ECF HTTP client. Having this in mind, how the "Test" button should be implemented?
(In reply to comment #2) > Team component only provides proxy settings which are consumed by various > clients like JRE HTTP client and or ECF HTTP client. Having this in mind, how > the "Test" button should be implemented? I assume there is a well-defined semantic for these proxy settings. So, using these settings there could be behind the "Check connection" button a tiny implementation based on java.net.URL.openStream() see http://java.sun.com/docs/books/tutorial/networking/urls/readingURL.html http://www.vogella.de/articles/JavaNetworking/article.html In the case of an exception the user should see the exception details in a dialog.
(In reply to comment #3) It could happen that establishing a connection this way is successful but p2 doesn't work (or the other way around) because it uses ECF as a transportation layer. What about making the whole thing extensible? Each communication framework could provide a tester and the test button would run them all. The default tester would be provided by Team and delegate to JRE connection handler.
Wasn't it better to base all communication frameworks on a common low level code who'd handle proxy things?
(In reply to comment #5) > Wasn't it better to base all communication frameworks on a common low level > code who'd handle proxy things? Such decoupling is the whole point of having multiple frameworks. Also, it's technically impossible since frameworks use code developed outside the Eclipse foundation (like Apache HTTP client).
(In reply to comment #6) > Such decoupling is the whole point of having multiple frameworks. Also, it's > technically impossible since frameworks use code developed outside the Eclipse > foundation (like Apache HTTP client). Given that, I am for your suggestion.
Created attachment 177936 [details] initial patch Here is some initial work around this enhancement. The idea is to add extension point in org.eclipse.core.net and provide extensions in providers. The default extension is in org.eclipse.ui.net and tests standard java URLConnection. In this concept there is only one method testConnection in IProxyTestProvider. It causes that implementors should support different protocols in this one method. Different approach could be to add separated methods for each protocol (e.g. testHttpConnection for http protocol and so on). Now tests are executed just after user pressed Test button. At the end dialog displays results. Tests are performed for a host(s) defined in ProxyTester which is not a good solution. I think that the better idea is to show a dialog similar to this with test results but with modifiable host field. In this case there should be also Run button which executes these tests. After this dialog should be updated with test results.
Created attachment 183463 [details] proposed patch Here is a patch which is similar to the previous one. The main change is related to presentation layer. Now after Test button was pressed, there is a dialog with modifiable host which is used for testing purposes. Tests can be performed by pressing Run All button. The rest of the patch is the same (with some improvements).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
