Honor the environment variable for verifying the host at which the server is listening

[roguexz]

Sometimes, when running on a VPN, 0.0.0.0 is inaccessible and it forces me to set the QUARKUS_HTTP_HOST environment variable to localhost. There is one test case that does not honor the explicit environment variable setting. This PR fixes that problem.

I don't know if there is a better way of doing it, but I'm open to suggestions.

[gastaldi]

You can inject the config property in the test instead:

    @ConfigProperty(name="quarkus.http.host", defaultValue="0.0.0.0")
    String host;

[gastaldi]

LGTM

[gastaldi]

Hum, sorry, looks like it doesn't work with native 😞

[ERROR] Failures: 
[ERROR]   JaxRSITCase>JaxRSTestCase.testConfigInjectionOfPort:40 1 expectation failed.
Response body doesn't match expectation.
Expected: is null
  Actual: 0.0.0.0

[gastaldi]

What happens if you change to Instance<String> host and call host.get() in the test instead of String host?

[machi1990]

Injection is not yet supported in Native tests - https://quarkus.io/guides/getting-started-testing#native-executable-testing

[roguexz]

so, would you recommend that I move it back to checking for environment variables? That is what I started with originally.

[gastaldi]

@roguexz yeah maybe that would be the best in this case, WDYT @dmlloyd ?

[roguexz]

For a reference, my original commit had the following change,

RestAssured.when().get("/test/config/host").then()
            .body(is(System.getenv().getOrDefault("QUARKUS_HTTP_HOST", "0.0.0.0")));

If you are ok with it, I can update the commit.

[gastaldi]

Isn't easier to just check if the body response is not empty or null?

[roguexz]

@gastaldi The original test was checking for 0.0.0.0. As part of debugging another issue, I noticed this scenario.

[gastaldi]

I know, I mean that the possible values for this test are localhost or 0.0.0.0, so I wonder if isn't easier to just check if the result matches one of those values

[gastaldi]

Just another shot: try getting the quarkus.http.host from ConfigProvider.getConfig().

[gastaldi]

The reason is that we should avoid reading from System.getenv() or System.getProperties() and use MP Config where possible

[roguexz]

Agreed. Wouldn't the suggested fix do the same, giving the additional possibility of honoring a system environment value? I am good either ways. What would you recommend?

[gastaldi]

I'm fine with either TBH ;)

[roguexz]

@gastaldi Done. I have switched to using MP config instead.

[geoand]

Thanks for this!