On Mon, Feb 9, 2015 at 10:25 AM, Bobby Evans <[email protected]> wrote:
> Yes we would get rid of the log4j-over-slf4j, which is not that commonly > used in libraries anyways, and replace it with the log4j-1.2-api jar. That > prevents slf4j from seeing a logging feedback loop. - Bobby > If you mean that log4j-over-slf4j is not commonly used in libraries (that is, non-app jars) specifically, I might agree with you--a good library citizen should log only to slf4j and not make any assumptions about the consuming app's selection of logging engine. And adding log4j-over-slf4j to a library's dependencies makes the already somewhat painful job of unifying logging more difficult. But if you mean that apps themselves don't typically use log4j-over-slf4j then I would disagree with you rather strongly. Any user of Logback has probably used log4j-over-slf4j because someone has rudely chosen to log directly to log4j and the log events must be intercepted and redirected. I don't say that to rag on Log4j--it's a fine logging engine. It's just not designed as a logging abstraction (we're talking 1.x here). Personally I prefer Logback, but whatever the solution selected I would implore the Storm community to scope Log4j/Logback with runtime scope and only log to the slf4j api. This makes future changes cheap and reduces the chances of misuse. The correct solution to the problem is https://issues.apache.org/jira/browse/STORM-129, of course. I don't suppose there's been any progress with classloader isolation? -j
