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 >> >
