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 the window completely as the http
server
creates its own server sockets and there would be no way to guarantee
that any
particular port is free at that moment.
Maybe, one possibility is to catch the BindException, and return a
specific error
code from the child process which forces a retry?
- 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
