Simplify Log4j backend configuration

[google]

Simplify Log4j backend configuration

[clehene]

@hagbard the original issue was about simplification (it is indeed complicated and confusing to figure out why flogger decides to go with JUL instead of slf4j).

Having to have system-backend is another complexity aspect. It's against intuition to require a dependency for the backend that you're trying to override.

To use flogger with logback I have to do the following voodoo

    <dependency>
      <groupId>com.google.flogger</groupId>
      <artifactId>flogger</artifactId>
    </dependency>
    <dependency>
      <groupId>com.google.flogger</groupId>
      <artifactId>flogger-system-backend</artifactId>
    </dependency>
    <dependency>
      <groupId>com.google.flogger</groupId>
      <artifactId>flogger-slf4j-backend</artifactId>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
    </dependency>
    <dependency>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-core</artifactId>
    </dependency>

Then make sure a system property is set

System.setProperty("flogger.backend_factory", "com.google.common.flogger.backend.slf4j.Slf4jBackendFactory#getInstance");

Then instantiate the logger

private static final FluentLogger logger = FluentLogger.forEnclosingClass();

[hagbard]

I've avoided going with any "just find it on the classpath" approaches for several technical reasons. I tried it initially but ran into several issues in cases when more than one backend was present. It's also much slower to start if you need to search a really big classpath (Google has some very large class paths for its binaries).

The need for flogger-system-backend is just so there's a completely reliable fallback if the named backend doesn't exist. It could probably be removed but then the binary would have to throw an error if no backend was available.

The reason the backend and core library are split (rather than just being together in one library) is that the core library is Java6 source compatible and the current JDK backend uses Java7 features.

I hope this helps explain things.

[hagbard]

I just remembered that one of the reasons we didn't do this was to have a consistent approach with Android, where the SPI style of approach just doesn't work, and reflection is very expensive.

[medb]

FWIW, I ended up with copying com.google.common.flogger.backend.system.DefaultPlatform class in my project and overriding default logger in it:
https://github.com/GoogleCloudDataproc/hadoop-connectors/pull/310/files

It would be nice to have multiple flogger-<backend>-default artifacts that have a default static binding for different backends, e.g. flogger-log4j-default, etc.