Skip to content

Added LogbookCustomizer for Spring#2234

Open
paul-kraftlauget wants to merge 2 commits intozalando:mainfrom
paul-kraftlauget:feature/spring-logbook-builder-customizers
Open

Added LogbookCustomizer for Spring#2234
paul-kraftlauget wants to merge 2 commits intozalando:mainfrom
paul-kraftlauget:feature/spring-logbook-builder-customizers

Conversation

@paul-kraftlauget
Copy link

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

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

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:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All commits are signed

Signed-off-by: Paul Johe <paul@kraftlauget.no>
Signed-off-by: Paul Johe <paul@kraftlauget.no>
- [Credits and References](#credits-and-references)
<!-- tocstop -->
Copy link
Author

Choose a reason for hiding this comment

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

sorry, intellij automatically made these changes. Are they ok, or shall I revert them?

Copy link
Member

@kasmarian kasmarian left a comment

Choose a reason for hiding this comment

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

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.*;
Copy link
Member

Choose a reason for hiding this comment

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

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) {
Copy link
Member

Choose a reason for hiding this comment

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

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();
    }

@kasmarian kasmarian added the minor Minor changes label Feb 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

minor Minor changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants