WebClient used in SE examples and tests

[Verdent]

Signed-off-by: David Kral david.k.kral@oracle.com

[tomas-langer]

@romain-grecourt can you please have a look?
I have two issues seeing it now:

1. The registration of readers and writers is a bit too much. Maybe we should come up with some level of automation?
2. The tests that need to do toCompletableFuture().get() to make sure the reactive path finishes before the method finishes seems ugly (though necessary) - maybe we should come up with a simple wrapper that would be synchronous (either as a testing support library, or maybe even as API)
   Ideas?

[Verdent]

I was thinking about some WebClient wrapper for Helidon tests. Because when you look into the PR, it contains a lot of duplicity code ... What I am struggling with currently is, how to make it as simple as possible.

[spericas]

Perhaps some of these simplications should be offered to developers as well (if not already there!). E.g., if I want to add JSON support, why can't I do that in a single line with reasonable defaults?

.mediaSupport(JsonProcessing.class)

or something similar. CoC can coexist with the no magic style.

[Verdent]

Yes I definitely agree that some simplification for users is required also.

• Your proposed simplification would be nice if we want to have reader and writer registered by default. But I am not exactly sure if we can do it currently. It seems to me that media support providers are currently not done the same way and creation of each reader and writer is done differently for each provider.
• It could be possibly also nice to have something like addReader(MessageBodyReader instance) and the same for writer directly at builder. Because you might want to have reading handled by your own reader but writing handled by some default etc. But to this we probably need to update MediaSupport to allow creation of the new MediaSupport instance based on the previously created one.

[romain-grecourt]

I agree that MediaSupport needs a way to replicate the current "media support" services.

Shortcut methods on the builder for registering readers and writer also sounds like a good idea.

Also registerDefaults() could also be implied by default, and we'd have a flag to not register the defaults.

E.g.

MediaSupport.create() // MediaSupport with defaults

MediaSupport.builder(false) // does not register defaults
    .reader(FooReader.create()) // shortcut for .readerContext().registerReader(...)

MediaSupport.builder() // registers defaults
    .operators(JsonMediaSupport.create()) // registers all supported operators for JSON

[romain-grecourt]

2. The tests that need to do toCompletableFuture().get() to make sure the reactive path finishes before the method finishes seems ugly (though necessary) - maybe we should come up with a simple wrapper that would be synchronous (either as a testing support library, or maybe even as API)

Having that as part of the Multi / Single API would be nice. Let's chat with Daniel and David about that. Though I think that this is okay to leave as-is for now.

[romain-grecourt]

Maybe these could be changed to just throws Exception ? Or maybe like Tomas said we need to come-up with a small utility and wrap the exceptions.

[danielkec]

Maybe something like utility method await to hide dirty blocking? Its quite common in reactive tcks:

WebClientResponse response = await(webClient.get()
                .path("/employees")
                .request());
response.close();
Assertions.assertEquals(Http.Status.OK_200, response.status(), "HTTP response2");

I would definitely add some timeout

[Verdent]

Fixes #1668

[romain-grecourt]

@tomas-langer Can this PR go in without the new Single features?

[tomas-langer]

Follow up: #1748

[tomas-langer]

LGTM