Bug 299020

Comment 1 Juergen Weber 2010-01-07 05:01:22 EST

Created attachment 155480 [details]
Apache Directory Studio's check connection dialog

Comment 2 Pawel Pogorzelski 2010-01-07 09:58:15 EST

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?

Comment 3 Juergen Weber 2010-01-07 10:14:18 EST

(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.

Comment 4 Pawel Pogorzelski 2010-01-07 11:46:23 EST

(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.

Comment 5 Juergen Weber 2010-01-07 13:10:07 EST

Wasn't it better to base all communication frameworks on a common low level code who'd handle proxy things?

Comment 6 Pawel Pogorzelski 2010-01-08 05:16:39 EST

(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).

Comment 7 Juergen Weber 2010-01-08 05:24:06 EST

(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.

Comment 8 Wojciech Galanciak 2010-09-01 07:05:39 EDT

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.

Comment 9 Wojciech Galanciak 2010-11-19 07:03:55 EST

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).

Comment 10 Eclipse Webmaster 2019-09-06 16:06:49 EDT

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.