Request log implementation

[zUniQueX]

As already stated in #4720 (comment), logback-access seems to stay behind Jetty's current implementation quite a long time and introduces bugs like the 100% CPU bug. Therefore I think it could be reasonable to provide an implementation of Jetty's CustomRequestLog.

Should this be provided in a seperate module or integrated into the dropwizard-request-logging module? And should this be registered by default in Dropwizard 3.x.x onwards or should we stay on the logback-access implementation in the default configuration?

[mattnelson]

If the current default is that problematic, then it should no longer be the default.

[zUniQueX]

That's why I'm asking this. As the Jetty team has provided a PR for the issues, this could get fixed soon. But the current logback branch without the jakarta upgrade (logback 1.2.x) has a dependency for Jetty 8.2.x and I'm therefore not convinced Jetty 10.x.x will work without problems in the next time.

[zUniQueX]

Dropwizard already has the LogbackClassicRequestLogFactory which internally uses Jetty's CustomRequestLog. After upgrading to Jetty 10.x and 11.x, we can probably reduce our code by using Jetty's Slf4jRequestLogWriter and the CustomRequestLog.EXTENDED_NCSA_FORMAT pattern (this seems to be nearly identical to the current pattern).

@dropwizard/committers Do you think we could/should switch to the Jetty implementation in Dropwizard 3 and 4? As we have to rely on Jetty anyway, I personally see less problems using their RequestLog implementation.

The benefit would be, that we could migrate to Dropwizard 3 now.

[jplock]

That sounds like a good idea to me.

[zUniQueX]

Should we then temporarily drop support for the logback RequestLogImpl in DW 3 until the issue is fixed?