Comment 1 Martin Aeschlimann 2006-04-10 17:39:29 EDT

bug 133348 is rather long. Can you give reproducable steps for the bug here?

Comment 2 Olivier Thomann 2006-04-10 21:02:29 EDT

Damien,

Could you please indicate the steps you tried to get rid of the javadoc attachment?
From what I understood, you tried the following steps:
1) Start a new workspace
2) Start a new java project
3) Edit the JRE libraries and try to remove the javadoc attachment for the rt.jar.
I tried and the javadoc attachment was removed.
In one case, I had the same problem, but I could not reproduce.

Comment 3 Damien Lecan 2006-04-13 04:08:30 EDT

With Eclipse 3.2M6
1) Start a new workspace
2) Start a new java project
3) Edit the JRE libraries and try to remove the javadoc attachment for the
rt.jar

Javadoc attachement is removed in HMI, but then, if I try to get 'l' class completion, I again get this error :

Java Model Exception: Java Model Status [Cannot retrieve the attached javadoc for l [in l.class [in sun.security.krb5.internal.ktab [in C:\Program Files\Java\jre1.5.0_06\lib\rt.jar [in Test]]]]java.net.ConnectException: Connection timed out: connect
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(Unknown Source)
	at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
	at java.net.PlainSocketImpl.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at java.net.Socket.connect(Unknown Source)
	at sun.net.NetworkClient.doConnect(Unknown Source)
	at sun.net.www.http.HttpClient.openServer(Unknown Source)
...

If I configure a http proxy (via -Dhttp.proxyHost ...), no problem (a bit slow, but no exception).

Comment 4 Olivier Thomann 2006-04-18 16:47:25 EDT

Martin,

This is pretty serious. If we cannot improve the connection when behind a firewall, it is important to be able to disable it.
It looks like it is possible to remove the javadoc attachment from the UI, but it is still set in the classpath entry. JDT/Core doesn't cache this information, we check if the javadoc attachment is set before we try to retrieve the javadoc for a type.

Comment 5 Martin Aeschlimann 2006-04-19 05:37:16 EDT

Note that the Javadoc lcoations for entries in container is not stored in the .classpath, but provided by the entries for the classpath container.

I can't reproduce this in N20060418-0010

How exactly did you remove the Javadoc location from the rt.jar?

a.) property page on rt.jar (in JRE contains): clear the field and press ok
b.) preferences - installed JRE's

From the UI it looks as if the JRE container correctly updates it's entries.

Comment 6 Damien Lecan 2006-04-20 05:06:37 EDT

I cannot reproduce problem with Eclipse 3.2RC1 I20060413-1718.

If I remove javadoc attachement ( a) or b) solution), no problem with completion anymore.

By the way, firewall configuration UI should be provided, instead of defining -Dhttp.proxyHost... or using internal javadoc URL.

Thanks

Comment 7 Martin Aeschlimann 2006-04-20 08:41:04 EDT

Olivier, can you still reproduce it?

I think we should provide a way to disable the Javadoc lookup somehow, e.g. a preference setting. 

Comment 8 Olivier Thomann 2006-04-20 09:52:56 EDT

No I can't. I could only get it once. A preference would actually be the best solution. But this would need to be done at the UI level.
The good point with a preference is that it would take one change to disable it instead of manually changing all javadoc attachment.
The problem is that I don't know if we can add a preference for RC2. Might be too late for 3.2.

Comment 9 Olivier Thomann 2006-04-21 10:55:06 EDT

This should be a polish item.
Adding a preference in the UI to disable the javadoc attachment globally would be an improvement for the user.
No need to manually edit each entry of the classpaths or the JRE container.
Martin,
We should add an option on the UI side. The JDT/Core API would be called only if the preference is set.

Comment 10 Dani Megert 2006-04-21 11:11:50 EDT

-1 for a UI only solution. We don't want to check that flag.

Comment 11 Martin Aeschlimann 2006-04-21 11:17:33 EDT

I more thought of a jdt.core setting where people that not online could prevent unnecessary web accesses with one click.
Javadoc settings are shared in a team and removing the location isn't a good solution (information is lost).

This can't be UI option as the access embedded in calls like IMethod.getParameterNames or code assist.

Comment 12 Olivier Thomann 2006-04-21 11:21:34 EDT

The current API doesn't say anything about a preference.
So changing the core side would require to modify the existing API.

Comment 13 Martin Aeschlimann 2006-04-21 11:32:43 EDT

The API's can't guarantee results as everyting depends if a web location can be reached or not. So I don't think there's a need to mention such an option (do you mention the timeout option?). 

Maybe this option can be folded together with the timeout option, e.g. timeout == -1

Comment 14 Olivier Thomann 2006-04-21 11:59:39 EDT

I added bug 137975.
Please continue the discussion there. Having a project's specific option should be good enough. Of course the ui should then expose it.

Comment 15 Martin Aeschlimann 2006-04-23 16:44:15 EDT

closing this bug as worksforme, can't reproduce anymore.

Damien, for the proxy configuration, I agree. Can you file this in a new bug against platform.ui?

Comment 16 Damien Lecan 2006-04-25 12:27:15 EDT

In fact, it has been discussed many times, so I won't fill in a new bug
See bug #97423, bug #119278, bug #92897, ...