Comment 1 Laird Nelson 2004-06-23 10:24:44 EDT

One further update: I've tried various workarounds for this, but can't come up 
with anything that both lets the test run and prevents this error from 
occurring.

Workaround 1: turn off proxy, add "-DsocksProxyHost=localhost -
DsocksProxyPort=1080" to test case configuration.  This seems to just cause 
the JUnit test to terminate without any output.

Workaround 2: try the above with IBM and Sun VMs (maybe IBM's JVM doesn't 
respect those properties?).  Same result.

Workaround 3: turn off proxy, run WSAD/Eclipse under SocksCAP, which *should* 
mean that all access should be transparent.  Certain network connectivity in 
Eclipse works fine; JUnit test cases fail with connection timeout errors 
indicating that for whatever reason the java process is not inheriting its 
SocksCAP-wrappedness from the parent Eclipse process.

Comment 2 Laird Nelson 2004-06-23 11:31:03 EDT

In related news :-), running through an HTTP proxy gets around the -port 
error, but any URLConnection opened inside a JUnit test running via the JUnit 
plugin in Eclipse will not have its proxy host or port set properly.  The net 
result is that even without SOCKS but with an HTTP proxy I cannot connect from 
a class being run inside a JUnit test.

Comment 3 Erich Gamma 2004-06-23 13:23:58 EDT

JUnit creates an ordinary socket connection to the target VM. So I wonder 
whether you can debug Java programs with Eclipse while SOCKS is enabled?

Can you please add the command line that is used to invoke JUnit to the bug 
report. To do so select the JUnit target in the Debug view and open the 
properties dialog. It will show you the process information.

The obvious workaround is to use the JUnit text runner and run your tests as a 
Java program.

Comment 4 Laird Nelson 2004-06-23 13:37:51 EDT

Hi, Erich; first, here's the command line to *run* a JUnit test case with 
SOCKS enabled in the workbench:

C:\WSAD5.1.1\eclipse\jre\bin\javaw.exe -classpath 
C:/WSAD5.1.1/eclipse/plugins/org.eclipse.jdt.junit_2.1.1/junitsupport.jar;C:\wo
rkspace\inst_nb\Sand\target\classes;C:\home\lnelson\.maven\repository\bsf\jars\
bsf-2.2.jar;C:\home\lnelson\.maven\repository\junit\jars\junit-3.8.1.jar 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner -port -1 -classNames 
sand.files.TestCaseDownloadableFile

Note "-1" specified as the port argument.

Now, if I try to *debug* the test case, I get a dialog box error:

Exception occurred during launch

Reason:
  Cannot find a free socket for the debugger

...so yes, you appear to be correct; debugging in general probably doesn't 
work.  I'll check this.

I've worked around the problem, incidentally, by turning off the SOCKS proxy 
and passing "-Dhttp.proxyHost=localhost -Dhttp.proxyPort=8000" as VM arguments 
to my test case.  This seems, in fact, the only way to get proxy information 
passed to the JUnit process.  In my case, I'm running Guidescope on my box 
that in turn chains to a SOCKS proxy (Putty with dynamic port forwarding) so 
that allows me to get out.

Comment 5 Erich Gamma 2006-05-24 05:48:30 EDT

Moving back to the JDT/UI inbox

Comment 6 Martin Aeschlimann 2006-06-23 13:59:58 EDT

Darin, do you provide special support for this in debug?

Comment 7 Darin Wright 2006-07-05 11:58:15 EDT

We do not provide any special support for this in debug. We use the Java class libraries to choose a free port on which to debug via our SocketUtil class:

/**
 * Returns a free port number on localhost, or -1 if unable to find a free port.
 * 
 * @return a free port number on localhost, or -1 if unable to find a free port
 * @since 3.0
 */
public static int findFreePort() {
	ServerSocket socket= null;
	try {
		socket= new ServerSocket(0);
		return socket.getLocalPort();
	} catch (IOException e) { 
	} finally {
		if (socket != null) {
			try {
				socket.close();
			} catch (IOException e) {
			}
		}
	}
	return -1;		
}	

Comment 8 Markus Keller 2006-07-06 10:46:34 EDT

Won't fix this specially for JUnit, given that plain debug has the same problems. Waiting for a decision for global proxy handling in bug 119278.

Comment 9 Denis Roy 2009-08-30 02:05:23 EDT

As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.