On 4 May 2016, at 23:59, Michael McMahon <michael.x.mcma...@oracle.com> 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
> 
> On 04/05/16 19:12, Chris Hegarty wrote:
>> 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 more work, and possibly
>> require some refactoring ).
>> 
>> -Chris.
>> 
>> 
>> On 4 May 2016, at 17:06, Michael McMahon <michael.x.mcma...@oracle.com> 
>> 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 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 till now.
>>> 
>>> So, I have updated the webrev at:
>>> 
>>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/
>>> 
>>> to remove the redundant permission check and also the following changes
>>> 
>>> 1) There was a bug in the permission check where the host part of the URI
>>>    was checked, but should have been the entire authority field. 
>>> (Utils.java)
>>> 
>>> 2) Add explicit test for a request URI and a real (randomly chosen) port 
>>> number
>>>    (test 1 in Security.java)
>>> 
>>> 3) Fixed another strange issue in the Security test which causes failures 
>>> if the jtreg
>>>    work directory is not empty prior to running the test. (change in 
>>> Security.moveFile)
>>> 
>>> Thanks,
>>> Michael
>>> 
>>> On 03/05/16 15:47, Roger Riggs wrote:
>>>> 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 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
> 

Reply via email to