network tests

[Jonathan Gibbons]

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.