Completely right, was just commenting that this was the motivating case,
SLF4J -> JUL, rather than JUL -> something else. It would fail at runtime
if you removed this dependency, but that is necessary. I agree with not
depending directly on this class.


On Thu, Apr 10, 2014 at 7:37 AM, Patrick Wendell
<notifications@github.com>wrote:

> In core/src/main/scala/org/apache/spark/Logging.scala:
>
> > @@ -135,4 +136,6 @@ trait Logging {
> >  private object Logging {
> >    @volatile private var initialized = false
> >    val initLock = new Object()
> > +  SLF4JBridgeHandler.removeHandlersForRootLogger()
>
> @srowen <https://github.com/srowen> the case I'm concerned about is the
> following. Someone wants to map SLF4J to JUL, so they'd need to remove the
> "jul-to-slf4j" dependency otherwise they'll get a routing loop. But then
> spark won't compile because this code depends on the SLF4JBridgeHandlerwhich exists only in the "jul-to-slf4j" jar. Am I missing something, or
> won't this cause a compile error for a user in that situation?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/apache/spark/pull/325/files#r11471909>
> .
>