On 14.2.2014 15:54, Daniel Fuchs wrote:
BTW - it occurs to me that it doesn't really matters which process opens the ServerSocket - does it? So you might as well create the server socket before calling jcmd() - can't you?
Yes, actually, the socket server could be created at the beginning of the test. That would resolve all the port number passing.
-JB-
-- daniel On 2/14/14 3:43 PM, Daniel Fuchs wrote:Hi Jaroslav, I agree with the idea, but the following logic looks suspect: 378 for(String arg : args) { 379 if (arg.startsWith("-")) { 380 pbArgs.add(0, arg); // VM arg 381 } else { 382 pbArgs.add(arg); // application arg 383 } 384 } it will inverse the orders of VM args in the sub process, and will have unpredictable results if any of those args accept parameters - such as '-cp <classpath>' which would result in <classpath> being taken as an application arg. It's difficult to say whether such a situation can or can't happen, but I suspect it would be safer to simply look for the "allocate_port" string or pass the "allocate_port" as a system property (e.g -Dallocate.port=true) - which would remove the need for that loop... best regards, -- daniel On 2/14/14 2:39 PM, Jaroslav Bachorik wrote:Please, review this test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 The test is currently using a well-known SSH port 22 to make sure it is not possible to start the management agent on this port. However, this may fail when SSH server is not running on a test machine. The fix adds the possibility to to start up a dummy socket server in the tested application and use the port from that socket server to make sure that the management agent refuses to start on that port. Thanks, -JB-
