Inject Logback logger into log writer, rather than a static field

Detailed Description

With version “1.13.0” I could inject a mock SLF4J logger bean named “httpLogger” into tests, and capture the calls of logbook, to verify my request/response behavior for logging. This was very helpful when logging is a 1st-class concern, and made testing straight-forward. (I discovered these fact experimentally.)

With version “2.0.0-RC.1”, the logger is a static field in `DefaultHttpLogWriter", and so not accessible for tests barring tricks. The code is:

public final class DefaultHttpLogWriter implements HttpLogWriter {

    private final Logger log = LoggerFactory.getLogger(Logbook.class);

    // ... rest omitted ...
}

The code for “1.13.0” is:

public final class DefaultHttpLogWriter implements HttpLogWriter {

    public enum Level {
        TRACE, DEBUG, INFO, WARN, ERROR
    }

    private final Logger logger;
    private final Predicate<Logger> activator;
    private final BiConsumer<Logger, String> consumer;

    public DefaultHttpLogWriter() {
        this(LoggerFactory.getLogger(Logbook.class));
    }

    public DefaultHttpLogWriter(final Logger logger) {
        this(logger, Level.TRACE);
    }

    // ... rest omitted ...
}

It would be helpful to recover this behavior in Logbook 2. Static fields make testing a challenge!

I believe my work around is to provide my own HttpLogWriter bean which uses an injected logger similar to how “1.13.0” worked.

[binkley]

@whiskeysierra Thank you for the sell and the suggestion. We’re using the captured HTTP traces from Logbook for several purposes, including:

• Replacing reliance on slow contract tests for non-contract concerns
• Validating Zipkin trace IDs in messages passed to Spring Controller and through Feign interfaces (we wrote a hook for Feign to direct it’s request/responses through Logbook)
• Validating Problem RFC responses for 4xx/5xx status codes
• Validating presentation of stack traces (lack thereof, actually) to clients in 4xx/5xx responses

In support, we use the JSON format for Logbook, so we can parse the log lines into Java POJOs:

https://github.com/binkley/spikes/blob/master/spring-boot-logging/src/test/java/x/loggy/HttpTrace.java

(This is a black-box approach, without wanting to hook into the innards of Logbook.)

SLF4J Test looks very interesting! That may be cleaner than using a Mockito mock for the logger. Thanks.

[binkley]

I’m behind the ball here, but to close this out – our general pattern is to inject the logger as a field. Combined with Lombok @RequiredArgsConstructor(onConstructor = @__(@Autowired)), the code overhead for developers is manageable.