As a slf4j user, FWIW, I think this approach is fine. Just note that you will have to handle log4j classes via reflection if they are not going to always be on the user classpath.
Is it sufficient to bundle log4j.properties? no programmatic config mess then. I don't know log4j enough to know if that accomplishes the goal. While we're on the topic, I see that additional slf4j shims are in place to route java.util.logging calls through slf4j and therefore on to log4j or whatever for centralized config. The same ought to be done for commons-logging, no? and we also should really exclude log4j and include log4j-to-slf4j if we really want people to be able to use something besides log4j. I can easily whip up a PR if anyone thinks that's a good idea. On Fri, Feb 7, 2014 at 2:31 PM, Patrick Wendell <pwend...@gmail.com> wrote: > Koert - my suggestion was this. We let users use any slf4j backend > they want. If we detect that they are using the log4j backend and > *also* they didn't configure any log4j appenders, we set up some nice > defaults for them. If they are using another backend, Spark doesn't > try to modify the configuration at all. > > On Fri, Feb 7, 2014 at 11:14 AM, Koert Kuipers <ko...@tresata.com> wrote: >> well "static binding" is probably the wrong terminology but you get the >> idea. multiple backends are not allowed and cause an even uglier warning... >> >> see also here: >> https://github.com/twitter/scalding/pull/636 >> and here: >> https://groups.google.com/forum/#!topic/cascading-user/vYvnnN_15ls >> all me being annoying and complaining about slf4j-log4j12 dependencies >> (which did get removed). >>
