1.3.0 exposes the ch.qos.logback.core package in the jar. JPMS builds will fail for most use cases because of this as logback-core is used widely by other libraries.
Yes, unfortunately, this one of the painful points for Dropwizard. The project originally was designed to work with Logback configured from an application YAML file and the default logging configuration pokes around in Logback internals to make it work. We've managed to adjust Dropwizard to work with other logging providers (#1900, #2112), but you have to manually exclude the logback dependencies from the core and make sure BootstrapLogging is not loaded by the classloader, which is obviously a kludge. Maybe in Dropwizard 2.0 we will be able to implemented a more modular approach.
I think the problem is here https://github.com/dropwizard/dropwizard/blob/117cd08130cfebb1e78345672edf7b922d6e215e/dropwizard-logging/src/main/java/ch/qos/logback/core/recovery/ResilentSocketOutputStream.java#L54
This method is not overrideable from outside the package. Maybe we can ask over here http://jira.qos.ch/secure/IssueNavigator.jspa to open it to be overrideable by any subclass?
I've opened a ticket here: https://jira.qos.ch/browse/LOGBACK-1400
I've also opened a PR for Logback to fix it: https://github.com/qos-ch/logback/pull/417
But there wasn't a commit to logback since February and there are a lot of open PRs. So I don't expect anything soon.
What else can be done in Dropwizard? Extract the ResilentSocketOutputStream class in it's own jar file (e.g. module) which can be excluded in case an app wants to use another logging implementation?
Other ideas?
Is anyone aware of a workaround for this?
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days
This is still an issue
Addressed in #2925.
Most helpful comment
This is still an issue