-
Notifications
You must be signed in to change notification settings - Fork 41.2k
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
Conversation
b6c074d
to
9f2dafd
Compare
There was a problem hiding this 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) |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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) { | ||
|
There was a problem hiding this comment.
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. | ||
* |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
b298efb
to
10bf8e3
Compare
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
See gh-9522 and gh-9166.