Added LogbookCustomizer for Spring#2234
Added LogbookCustomizer for Spring#2234paul-kraftlauget wants to merge 2 commits intozalando:mainfrom
Conversation
Signed-off-by: Paul Johe <paul@kraftlauget.no>
Signed-off-by: Paul Johe <paul@kraftlauget.no>
| - [Credits and References](#credits-and-references) | ||
| <!-- tocstop --> | ||
There was a problem hiding this comment.
sorry, intellij automatically made these changes. Are they ok, or shall I revert them?
kasmarian
left a comment
There was a problem hiding this comment.
I like the idea, thank you for you contribution!
Could you please also add a test (or a few) in the autoconfiguration module where the customizer will be used? To avoid regression in this field. Could be a simple customization that's verified in the test, that checks that LogbookCustomizer beans are actually applied as expected.
| import org.zalando.logbook.ResponseFilter; | ||
| import org.zalando.logbook.Sink; | ||
| import org.zalando.logbook.Strategy; | ||
| import org.zalando.logbook.*; |
There was a problem hiding this comment.
we tend to not use start imports, could you please change it?
| @Bean | ||
| @ConditionalOnMissingBean(LogbookCreator.Builder.class) | ||
| @Scope("prototype") | ||
| public LogbookCreator.Builder logbookBuilder(final ObjectProvider<LogbookCustomizer> customizers) { |
There was a problem hiding this comment.
I wonder if we even need this prototype bean. Wouldn't it work the same if logbook bean would accept customizers and apply them?
e.g.
@API(status = INTERNAL)
@Bean
@ConditionalOnMissingBean(Logbook.class)
public Logbook logbook(List<LogbookCustomizer> customizers) {
var builder = Logbook.builder();
customizers.forEach(customizer -> customizer.customize(builder));
return builder.build();
}
Description
Added LogbookCustomizer functional interface and implemented the standard usage pattern
Motivation and Context
This gives the opportunity to have custom code to change the behavior of the builder. This is a common pattern already seen across many Spring components, giving the consuming application a lot of flexibility.
Furthermore, the LogbookCreator.Builder is now a prototype bean, applying the standard customizers. This means that if the application wants two different LogBook instances, for example one instance for WebFlux and a slightly different instance used with WebClient, this is very easy to acheive.
Types of changes
I am a bit unsure if this is considered a breaking change. It changes methods marked as internal APIs, so I think it should be ok.
Checklist: