Paulo Levi wrote:
Just realized you might be confused about the saving of the original
proxyselector in the test code. To be clear:
What is called and throws the StackOverflowError is the
UserProxySelector class. I just expected calling
url.openConnection(Proxy.NO_PROXY); not to call the userproxyselector
(or any ProxySelector) so it shouldn't recurse so no
StackOverflowException.
Saving the original proxy selector is just not to affect any other tests.
On Mon, Dec 7, 2009 at 3:43 PM, Paulo Levi <i30...@gmail.com
<mailto:i30...@gmail.com>> wrote:
Huh?
But it throws StackOverflowError. after installing
UserProxySelector and calling any method. Just to be clear it is
the right class, it is attached.
My java version:
E:\java\bin>java -version
java version "1.6.0_14-ea"
Java(TM) SE Runtime Environment (build 1.6.0_14-ea-b04)
Java HotSpot(TM) Client VM (build 14.0-b13, mixed mode)
Windows xp.
What's happening here is that the ProxySelector() is not called to check
whether the URLConnection should use a proxy but whether the Socket
should use a SOCKS proxy.
Hence the endless recursive loop.
If you're going to make network calls from the ProxySelector
implementation (which is not recommended), make sure you cover your
bases to avoid that kind of problem.
In your case, having select be:
@Override
public List<Proxy> select(URI uri) {
if (uri.getScheme().equalsIgnorCase("http")) { // Avoid the
"socket://" endless loop....
try {
//bug here, the java doc say that this will bypass the
installed
//proxyselector but it doesn't.
URL u = new URL("http://www.google.com";);
URLConnection conn = u.openConnection(Proxy.NO_PROXY);
conn.connect();
} catch (Exception ex) {
Logger.getLogger(UserProxySelector.class.getName()).log(Level.SEVERE,
null, ex);
}
}
return Collections.singletonList(Proxy.NO_PROXY);
}
I'm not sure this should be considered a bug. But it might be worth it
to add a few notes in ProxySelector javadoc to warn against such problems.
