Alan,
I can imagine two possibilities here:
1) pass a system property to each test that defines a config file in
properties format that canbe read by any test that needs it
2) allow a new option to main/applet/shell tests that define a config
value that will be passed to the test via a system property
or environment variable. Eg @run main/config=XYZ
The former requires less change to the test but does require the test
to be able to read files. The latter is a bigger change to the
spec but doesn't run into any security manager issues.
-- Jon
On May 24, 2008, at 6:29 AM, Alan Bateman wrote:
Joe Darcy wrote:
:
Could the classic networking tests be refactored a bit to be
centralized like the nio tests? Would it be natural for classic
networking and nio to get their host information from the same place?
There was a time when the networking tests had dependencies on quite
a few web servers, proxies, etc. but there was effort to replace
these tests so there should only be a few dependencies remaining. I
briefly looked at the tests today and I was surprised to only find
one test that attempts a lookup of a Sun internal host. The other
tests with dependencies weren't moved from closed->open. In any
case, it should be straight-forward to centralize the dependencies
into one place.
:
Even if the Sun-internal settings remain baked in, I think an easy
way to pass in a limited number of configuration settings is
appropriate and shouldn't be too hard to accommodate in the test
code. Presumably an interface like "openjtreg -
Dmy.config.options=foo ..." wouldn't be too awkward to use.
If by "baked in" you mean a default configuration file for when the
property or other knob isn't used then it seems reasonable. Are you
thinking of passing in the individual parameters as properties or
have one property to locate a properties/config file with the
settings?
-Alan.
