Skip to content

Auto-configure codecs in WebFlux server & client #9558

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 3, 2017

Conversation

bclozel
Copy link
Member

@bclozel bclozel commented Jun 20, 2017

See gh-9522 and gh-9166.

@bclozel bclozel force-pushed the codecs branch 2 times, most recently from b6c074d to 9f2dafd Compare June 20, 2017 21:12
Copy link
Member

@snicoll snicoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good :) I think that TestWebClient needs to be looked at, even if only on the surface because we'll need to make sure those settings are shared there as well for sure.

@Configuration
@ConditionalOnClass(CodecConfigurer.class)
@AutoConfigureAfter(JacksonAutoConfiguration.class)
@Import(JacksonCodecConfiguration.class)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JacksonCodecConfiguration is not a lot of code. Perhaps we should move it as an inner class of this one?


@Configuration
@ConditionalOnBean(ObjectMapper.class)
protected static class JacksonJsonCodecConfiguration {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extra inner class shouldn't be necessary. The conditional on bean can be moved to the bean definition.

@AutoConfigureAfter(CodecsAutoConfiguration.class)
public class WebClientAutoConfiguration {

private final ObjectProvider<List<WebClientCustomizer>> customizers;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storing the ObjectProvider is unusual, I am not aware of a place where we do that. Since you are creating such a bean in the same class, moving the injection point to the @Bean method is more clear IMO


@Override
public void customize(WebClient.Builder webClientBuilder) {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra space.

* An immutable version of {@link WebClient.Builder} that can be used to configure
* and create a {@link WebClient}. In addition to existing methods, it provides
* ways to register {@link WebClientCustomizer} instances.
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should mention somewhere that every call return a new instance. We probably have documented that on RestTemplateBuilder as well.

* Callback to customize a {@link WebClient.Builder} instance.
* @param webClientBuilder the client builder to customize
*/
void customize(WebClient.Builder webClientBuilder);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that the type you want to expose? I would have expected the new WebClientBuilder there.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's the one we want; otherwise WebClientBuilder.build would not work (we're building from WebClient.Builder there), and WebClientBuilder is stateless, so I'm wondering how the state changes should be saved between customize calls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, for some reason I had the idea we have a RestTemplateBuilderCustomizer but we obviously don't for the reason you've mentioned.

@bclozel bclozel force-pushed the codecs branch 3 times, most recently from b298efb to 10bf8e3 Compare June 23, 2017 13:34
bclozel added 3 commits July 3, 2017 11:23
This commit adds a new customizer interface for applying
configuration changes to `WebClient.Builder` beans:
`WebClientCustomizer`.

The new WebClient auto-configuration will make available, as a
prototype scoped bean, `WebClient.Builder` instances.
Once injected, developers can use those to create `WebClient`
instances to be used in their application.

`WebClientCustomizer` beans are sorted according to their
`Order` and then applied to the builder instances.

Closes spring-projectsgh-9522
This commit introduces `CodecCustomizer`, a new callback-based interface
for customizing the codecs configuration for WebFlux server and client.

Instances of those customizers are applied to the `WebClient.Builder`
and to the `WebFluxAutoConfiguration` (which deals with both WebFlux and
WebFlux.fn).

For now, only Jackson codecs are auto-configured, by getting the
`ObjectMapper` instance created by Spring Boot. Other codecs can be
configured as soon as WebFlux supports those.

Closes spring-projectsgh-9166
This commit applies what's been done in spring-projectsgh-9166 for WebFlux client and
server, but for the `WebTestClient` auto-configuration.

`WebTestClient` can be configured for mock or integration tests and this
change applies `CodecCustomizer` beans to the client being built.

Closes spring-projectsgh-9577
@bclozel bclozel merged commit f2e77e4 into spring-projects:master Jul 3, 2017
@bclozel bclozel deleted the codecs branch July 3, 2017 10:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants