[
http://jira.qos.ch/browse/LBCORE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10581#action_10581
]
Paul Gregoire commented on LBCORE-24:
-------------------------------------
First off I must say that I've grown very disenchanted with all the logging
frameworks out there. Problems like this just plain frustrating, there is way
too much "magic" happening behind our backs. But to get on with my comment..
I have tried for several days to get slf4j and logback to work in harmony with
Red5. Everything works well until you try to separate logging into web contexts
or red5 app instances, all logging continues to go the topmost default level. I
have created a log context selector, log filter, and log listener but they dont
work properly.. maybe you guys can see where i've gone wrong?
http://svn1.cvsdude.com/osflash/red5/java/server/trunk/src/org/red5/logging/
I have also tried to use the non-static non-final logging patter in my red5
apps but it doesnt improve anything.
> LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
> ---------------------------------------------------------------
>
> Key: LBCORE-24
> URL: http://jira.qos.ch/browse/LBCORE-24
> Project: logback-core
> Issue Type: Bug
> Components: Other
> Affects Versions: unspecified
> Environment: Operating System: All
> Platform: All
> Reporter: Jens Elkner
> Assignee: Logback dev list
>
> Since LoggerFactory obtains the LoggerContext to use in its static init
> stage, using a LoggerContextFilter as described in Chapter 8 is completely
> useless, since the JNDI selector is never consulted again.
> Digging deeper on that issue reveals, that using a ContextJNDISelector (even
> if it would work) rarely leads to the intended behavior (e.g. webapp related
> logging), and is probably not thread safe wrt. common practice and intended
> logging. E.g. in tomcat we have two different cases:
> a) each webapp provides its own slfj4*.jar as well as *logback*.jar
> b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or
> tomcat/share/lib
> c) a und b mixed
> Well, to get things right, one can say case c) is unsupported ;-).
> In case a) logback has its own playground, so using JNDI doesn't make sense
> at all, since the webapp/logback has its own playground - doesn't interfere
> with
> other web apps since loaded via its dedicated classloader.
> However case b) is a little bit more challenging. Here the LoggerFactory and
> other classes are !shared! between several webapps, since loading is
> delegated from the dedicated webapp classloader to the shared webapp
> classloader, which picks up everything in share/lib , common/lib. So right
> now in 0.9.7, even if one uses JNDISelector a per webapp logging is
> impossible: The first webapp, which asks for a LoggerFactory always wins! All
> other webapps, which ask later for a LoggerFactory.getLogger() will get a
> Logger from the LoggerContext associated with the first webapp, since the
> context is "cached", i.e. the JNDI selector gets never consulted again.
> Assuming the LoggerFactory problem gets fixed by using e.g.
> public static Logger getLogger(* *) {
> return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**);
> }
> there is still a problem wrt. common practice aka log* usage pattern and
> webapp shared classes, which can not be resolved by JNDI: Today most
> developer use something like:
> public class XY {
> private static [final] Logger log = LoggerFactory.getLogger(XY.class);
> ...
> }
> That implies the same problem, as with the current LoggerFactory bug: The
> class gets the Logger from the context associated with the first webapp,
> which needs the shared class. And that's why all other webapps, which later
> need this class will use the the logger context of the first webapp. So e.g.
> if webapp A is configured to log to /var/log/a.log and another webapp B is
> configured to log to /var/log/b.log the loging output of shared classes will
> always go to /var/log/a.log if webapp used the classes in question first, no
> matter on which thread aka in which webapp the shared classes are used.
> So even if LoggerFactory gets fixed, JNDI selector is of little use, if one
> wants to have a webapp dedicated log as soon as shared classes are involved.
> The only way to solve the didcated webapp log problem a can think of, to
> introduce another level of indirection in the Logger.log* etc. method, which
> takes care of thread local settings and the settings of its parent threads
> (e.g. an application may start other threads, which do not inherit the thread
> local settings from the current thread ...). But this would probably
> influence the performance of logback in a rather negative way.
> Another idea might be an architecture re-design: sharing Loggers would be no
> problem because of thread local AppenderContext soft ref, which points to an
> Appender in the global AppenderStore singleton ...
> RFE: These problems should be reflected chapter 8 of the logback manual to
> avoid further confusion ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
