Yes classloader isolation would be best, but the problem I always run into is
that clojure plays around with classloaders to get the runtime compilation to
work properly and the last time I poked around only one implementation of OSGi
would play nicely with clojure. That is not to say that we couldn't make
something work with just using classloaders directly, but I apparently am not
smart/experienced enough to make that work when I tried it last time. There
would always be odd errors that pop up inside totally unrelated clojure code,
and I didn't spend the time to really dig into it to understand exactly what
was happening.
- Bobby
On Monday, February 9, 2015 8:08 PM, Jeff Ramsdale
<[email protected]> wrote:
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
