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 :) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
