Add logback backend about flogger HOT 4 OPEN

Thanks for this information, it's hopefully going to be useful to anyone else.

The fact is that Google doesn't really use log4j or logback, so there's been no effort internally to make any of this work. If you felt up to writing a new backend to make this less "janky", I'd happily review it. Backends are pretty minimal, so getting something hacky to work as proof of concept shouldn't be too hard.

LoggerConfig is a JDK thing. It's not really part of the Flogger API, it's a convenience class to prevent a common misuse of JDK loggers (logger.getLogger() returns a weakly referenced instance causing weird race conditions in which logging configuration can be lost). I see it's caused confusion (for which I apologize). I should have given it a name that makes it clearer it's not intended to support general logging configuration for any Flogger backend.

I have to confess to knowing next to nothing about logback though, so if you think that supporting it "properly" will require changing internal APIs, please let me know.

from flogger.

Maybe subjective, but feels cleaner to have direct backend to logback. Then also, not a high priority, as flogger->slf4j->logkback seems to work well. I am subscribing to this issue, so one day if it is resolved, I can clean the dependecies a bit :)

from flogger.

Some feedback on getting logback to work.

I adapted and fixed some bugs in this version. I doubt it is an ideal implementation especially since it's not implemented against the latest backend loading changes.

When it worked

It worked ok with simple classpaths -- it even worked alongside dropwizard. Reconfiguring loggers programatically via the LoggerConfig was not working with this approach however.

When it didn't

For testing scenarios certain logback class paths made it impossible to get the platform loaded. Controlling classpath traversal in a test with multiple rules is quite hard. The classpath contained multiple logback.xml's but I think the main issue was the classloading order. Debugging the issue did reveal the custom backend registration hooks were being called if I tried to control the classloading order -- but in practise the default backend classes were being used.

Just using the slf4j bridge seems to be the most reliable approach

I spent quite some time trying to get around it -- eventually I decided to try the slf4j bridge via logback. This works very well. As far as I can tell config from logback.xml is propagating to JUL and using the LoggerConfig also works.

In test code I use this LevelChangePropagator as a way to execute the init block reliably.

class AxsyConfigurator: LevelChangePropagator() {
    init {
        if(!SLF4JBridgeHandler.isInstalled()) {
            LogManager.getLogManager().reset()
            SLF4JBridgeHandler.install()
        }
        setResetJUL(true)
    }
}

with this in logback.xml

    <contextListener class="...logback.AxsyConfigurator"/>

The slf4j bridge works well, I don't know if there are any hidden costs in the bridging layer.

from flogger.

I've just looked at logback and it's licensed under the LGPL and EPL (simultaneously), but not ASL.
While it's still possible to have a Google project depend on software developed with the EPL (1.0) license, it's more work, so for now I've chosen to concentrate on a log4j2 backend right now (unless someone can give me a really compelling story as to why it's worth the additional effort to support logback first).

Obviously anyone else is welcome to support logback themselves if they so wish, but the reciprocity of the EPL license makes developing with inside Google more awkward.

from flogger.