----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
On 3/2/12 8:04 AM, Stuart Douglas wrote:
>
> On 03/03/2012, at 12:31 AM, Pavel Janousek wrote:
>
>> Hi,
>>
>> I've investigated some issue now and seen there are several places
>> in TS where we can see similar code like this:
>>
>> static final String someIPproperty = System.getProperty("<some
>> key>", "localhost");
>>
>> or
>>
>> static final String someIPproperty = System.getProperty("<some
>> key>", "127.0.0.1");
>>
>> As you can see above, this fallback mechanism is bound in this
>> case (key value isn't found) to IPv4 only IP address at all. This
>> approach is bad because we can run in other network stack - IPv6
>> is presented in these days - and in this case the such testcase
>> fails with some strange error due to this issue.
>
> The fallbacks are there for cases when no other stack is specified.
> As of today the test suite should honour all setting specified by
> the node0 and node1 addresses. If you are running under another
> network stack and have configured the build properly then these
> fallbacks should never be hit, they will only be used in the
> normal mvn install case with not other addresses set.
>
> To be honest this sort of fallback should probably be implemented
> in the pom, so that the system properties are always defined. Feel
> free to volunteer to fix it.
>
+1; it would be nice to know these are always set in the pom. Then
when
reviewing a patch, the presence of "localhost" or "127.0.0.1" is
grounds
for kicking it back, with no need to even think about it.
So could be a conclusion from related topic - the JIRA about request to testsuite
structure maintainer(s) to accommodate and guarantee this request/feature set-up in every
place(module) plus clean-up testcases java code to remove this fallback mechanism from
java source code at all?
If so, I'll rewrite one already filled placeholder...
Pavel