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.
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.
I have seen similars problems since the integration of centralized proxy management, jrechtacek may know more. CVS currently does not contain any "proxy" code.
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
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.
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.
*** Issue 97478 has been marked as a duplicate of this issue. ***
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.)
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.
With the agreement of Maros was reassigned to cvs.
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
the same for subversion
FWIW, I am able to get CVS working through cltea-proxy.sun.com:1080 (configured in Gnome proxy settings, after restarting IDE).
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.
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