commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Date Fri, 24 Apr 2009 15:37:33 GMT
Ceki Gulcu wrote:
> Mark Thomas wrote:
>> Sorry if I wasn't clear. I intended that the slf4j jars and the third
>> party jars were all in WEB-INF/lib
>> My concern in this scenario is more that this j.u.l, as part of the JRE,
>> will be loaded by the System class loader and hence loggers are
>> registered JVM wide rather than per webapp. Does slf4j provide a way
>> around this issue?
> Thank you for your response. Actually, I am unable to understand what
> the issue is. So I can't answer whether SLF4J would be helpful or
> not. In principle, SLF4J does not provide any mechanism whatsoever to
> get around class loading issues. It only follows a two step recipe: 1)
> attempt to load a class named StaticLoggerBinder which ships within
> each slf4j binding 2) Each binding in turn will try to bind with a
> specific logging framework. It's a very dumb and rather inelegant
> approach which I would not recommend except in the context of
> logging. SLF4J does not use class loaders directly.
> Anyway, while I understand that j.u.l. classes are part of the JRE, I
> don't see what difference it makes in this scenario.

Just that the root cause of the particular issue I described (which has
moved away from the subject line a little) is the way j.u.l registers
logging. I was curious if slf4j did anything to workaround the issues
that presents.

Thanks for the clarification.

I think I need to go away and test slf4j with the various logger
framework / classloader issues I have seen over the years and see if any
of them remain. Now I just need to find the time to do it :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message