Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

On 4 May 2016, at 23:59, Michael McMahon wrote: > I've just updated the webrev at > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.3 > > to retry the tests in the unlikely event of a BindException Thanks Michael. This looks ok. -Chris. > - Michael > >

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

I've just updated the webrev at http://cr.openjdk.java.net/~michaelm/8155928/webrev.3 to retry the tests in the unlikely event of a BindException - Michael On 04/05/16 19:12, Chris Hegarty wrote: Michael, getFreePort follows a failed pattern. There is no guarantee that the port will be

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Hi Chris, The problem is that the port number needs to be allocated outside the test VM because it needs to be specified as a system property given to the test VM. This system property is then evaluated in the policy file to give permission to that port. I can't think of an easy way to close

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Michael, getFreePort follows a failed pattern. There is no guarantee that the port will be “free” when you actually require it. It will only reduce the likelihood of failure. Is there any way that the actual tests needing the port can create it themselves ( i understand that this will be

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Hi Michael, Looks good, Roger p.s. btw, the webrev diffs for 'Wdiffs' don't show anything. On 5/4/2016 12:06 PM, Michael McMahon wrote: Hi Roger, Thanks for the review. That permission is not actually required for the test. But, it did make me look closer at it, and I realised that

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Hi Roger, Thanks for the review. That permission is not actually required for the test. But, it did make me look closer at it, and I realised that permission checking of the request URI port number was not being tested. So, that led me down a couple of rat holes which is why I haven't replied

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Hi Michael, test/java/net/httpclient/security/15.policy: line 15: - Should this policy file include the substitution for the ${port.number}? Otherwise, it still looks like it has a fixed port #. Roger On 5/3/2016 7:44 AM, Michael McMahon wrote: Some tests with hardcoded port numbers

RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Some tests with hardcoded port numbers were included in the initial http tests. The fix uses a driver to allocate a free port and pass it into the existing security test through a system property. http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html Thanks, Michael