This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 98263 - CVS connections through webcache no longer work
Summary: CVS connections through webcache no longer work
Status: RESOLVED FIXED
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: CVS (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: issues@versioncontrol
URL:
Keywords: REGRESSION
: 97478 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-03-19 21:11 UTC by Jesse Glick
Modified: 2007-05-25 15:25 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-03-19 21:11:45 UTC
I use dev builds on JDK 7. I have noticed for maybe a couple of weeks now (?)
that I can no longer do CVS operations on netbeans.org using the IDE when I am
on SWAN. My Gnome Network preferences say to use webcache:8080, but from the IDE
I just get

  AuthenticationException: Cannot connect to host cvs.netbeans.org:2401

from PServerConnection.openConnection. This even in a fresh user directory;
using system proxy settings (the default).

Other operations such as Auto Update and blog display work. Switching proxy
settings in the IDE to manual mode (webcache and 8080) doesn't work either,
though I get a somewhat different message in the CVS connection failed dialog,
mentioning SOCKS (which I am not trying to use).

NB 5.5 works. Just 6.0 dev builds fail. If you need me to track down in which
6.0 build this stopped working, let me know.
Comment 1 Maros Sandor 2007-03-20 10:10:46 UTC
I have seen similars problems since the integration of centralized proxy
management, jrechtacek may know more. CVS currently does not contain any "proxy"
code.
Comment 2 Jiri Rechtacek 2007-03-20 21:17:28 UTC
Jesse, I have investigate the problem I guess I found the cause of reported
regression. The cvsmodule in NB5.5 handle proxing itself via own tricky code.
But the cvsmodule uses the shared proxy handling since NB6/M8.
The cvsmodule creates the Socket for NB CVS repository (i.e. netbeans.org:2401),
in currect code asks ProxySelector for Socks Proxy. In case any Proxy for Socks
protocol found then connection passes, it no Socks Proxy => it fails. In NB5.5
cvsmodule creates Socket for HTTP Proxy (e.g. webcache:8080), this Socket uses
as proxy for establish connection to netbeans.org:2401 and reads cvs data itself
(see at
<release551-root>/versioncontrol/src/org/netbeans/modules/proxy/ClientSocketFactory.java).

Capability like this the java Socket client doesn't have. Socket.connect()
rejects all Proxy types other than Proxy.SOCKS. For that reason a HTTP proxy
doesn't work in NB6.0.
I hope that nbexec should detect Socks settings from OS and solve most of case.
(btw. issue 97095 - Detect Socks Server on Gnome was fixed in today's sources),
I close as WONTFIX for now, I don't plan any support for HTTP protocol while
connecting to Socket. If I'm wrong, please reopen. Thanks
Comment 3 Jesse Glick 2007-03-21 01:57:23 UTC
Well this is quite unfortunate - NB 5.5 works out of the box and NB 6.0 does
not. Any plans to reinstate HTTP proxy support in the CVS module?
ClientSocketFactory.java still exists and still apparently contains code to use
an HTTP proxy, so I am confused by Jirka's implication that this feature has
been removed.
Comment 4 Maros Sandor 2007-03-21 10:35:18 UTC
Decision was made to centralize proxy configuration and handling to the
platform. I thus removed ALL proxy code from CVS. In my opinion I should NOT be
handling "special" cases like connecting to a server through HTTP proxy in CVS
module, this is just an ugly hack and not a real solution to this problem. If we
should hack something, it would be best to hack it in core - if it's possible,
for example work around JDK limitation somehow and connect via HTTPS proxies
manually.
Comment 5 Maros Sandor 2007-03-21 11:06:29 UTC
*** Issue 97478 has been marked as a duplicate of this issue. ***
Comment 6 Jesse Glick 2007-03-21 18:28:03 UTC
Well, I guess it's up to you whether you want to support it or not. I was just
caught by surprise at the functional regression; it was nice when NB "just
worked". Next time I am on SWAN I will check whether NB will automatically pick
up Gnome SOCKS5 settings and use them for CVS. (I don't currently have SOCKS5
configured for Gnome because I never needed to before.)
Comment 7 Tomas Stupka 2007-03-21 18:58:56 UTC
i'm in a similar situation with the subversion module when trying to connect to
a repository through https. 

1.) no socks proxy specified
Caused by: java.net.UnknownHostException: svn.collab.net:443
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:436)
 at java.net.Socket.connect(Socket.java:519)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:548)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:351)
 at
com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:71)

2.) with a socks proxy specified
Caused by: java.net.SocketException: SOCKS: Connection not allowed by ruleset
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:529)
 at java.net.Socket.connect(Socket.java:519) at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:548)
 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:351)
 at
com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:71)

There is only one scenario when the svn module works with sockets. It's when the
IDE has to retrieve the cerficate(s) from servers accessible via https so the
user may accept or reject them. Unfortunately, if this has to happen in the IDE
i don't see a way around opening a socket through https and if, for any possible
reason, this doesn't work, then the game is over and we have a regression for a
quite big group of subversion users. 
And if everything should, just for the socks settings detection, work fine (they
may not be set at all) then we still need a way how to explain to the user that
he needs to specify both a _http and a socks proxy_ even if the only thing he's
doing is e.g. to checkout from https://someserver.org. 

Comment 8 Jiri Rechtacek 2007-03-22 11:36:16 UTC
With the agreement of Maros was reassigned to cvs.
Comment 9 Maros Sandor 2007-03-22 11:40:16 UTC
Java is unable to connect through HTTPS proxies. We will either
1) plug into java's socket factories and help them with HTTPS tunneling
2) rollback recent changes in CVS and connect the old way
Comment 10 Tomas Stupka 2007-03-22 12:22:15 UTC
the same for subversion
Comment 11 Jesse Glick 2007-03-27 17:46:54 UTC
FWIW, I am able to get CVS working through cltea-proxy.sun.com:1080 (configured
in Gnome proxy settings, after restarting IDE).
Comment 12 Maros Sandor 2007-04-23 16:36:46 UTC
I have not found a way to plug directly into default socket factory so I think
that we have two options:

1) I will resurrect proxy code that I deleted from CVS module

2) We will introduce an API in the IDE, say NbSocketFactory, that would provide
https tunneling, or more generally, will provide proxy-enabled (socks, https)
sockets for IDE clients

If there are no oppinions encouraging #2 then I'll go for #1.
Comment 13 Maros Sandor 2007-05-25 15:25:18 UTC
CVS is now be able to connect through https proxies just like it did before.

/shared/data/ccvs/repository/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ClientRuntime.java,v
 <--  ClientRuntime.java
new revision: 1.45; previous revision: 1.44
/shared/data/ccvs/repository/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ui/wizards/RepositoryStep.java,v
 <--  RepositoryStep.java
new revision: 1.35; previous revision: 1.34
/shared/data/ccvs/repository/versioncontrol/util/src/org/netbeans/modules/proxy/ProxySocketFactory.java,v
 <--  ProxySocketFactory.java
initial revision: 1.1
/shared/data/ccvs/repository/versioncontrol/util/src/org/netbeans/modules/proxy/ClientSocketFactory.java,v
 <--  ClientSocketFactory.java
new revision: delete; previous revision: 1.1