[logback-user] Separating the logging-output of libraries in tomcat/shared

Robert Elliot rob at lidalia.org.uk
Mon Mar 1 14:00:07 CET 2010


Can't you sift on Thread.currentThread.getContextClassLoader()? That  
should be different per webapp.



On 1 Mar 2010, at 08:38, Achim Wiedemann <awn at inxmail.de> wrote:

> Hey Ceki,
>
> thanks for your fast reply. I tested your tip with the  
> SiftingAppender, but couldn't see how this gets me further compared  
> to the logging-separation described in Ch8 of the manual (separation  
> via JNDIContextSelector). The problem is still the same: The context  
> of the logger, once initialized, remains the same in shared  
> libraries. Since SiftingAppender has to sieve based on some criteria  
> (in my case the context), it also can't solve this issue.
>
> So I see, as you already stated, it's not possible to get this  
> scenario to work. However, thanks for your time and all your work.
>
>
> greetz,
> achim
>
>
> Ceki Gulcu schrieb:
>> Hello Achim,
>> Thank you for your message.
>> The only way to solve this issue transparently and perfectly would be
>> to introduce another level of indirection inside loggers so that each
>> logger-shell somehow delegate work to an inner logger attached to the
>> appropriate context. This is quite a difficult problem technically  
>> and
>> would generate significant computational overhead. I don't see the
>> problem fixed via such indirection any time soon. Read, as a logback
>> user, don't expect this problem to be solved without a little work on
>> your side.
>> As far as I can see, you have two options:
>> 1) move shared classes whose loggers you care about to the web-app
>> (unshare them)
>> If 1) is not an option, there is:
>> 2) Use a single shared logback.xml file with separation done by
>> SiftingAppender [1] using the context as separation criteria [2]. In
>> conjunction with prudent mode of FileAppender, you will be able to
>> separate logging by context.
>> Let me know if the above does not make sense.
>> [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender
>> [2] http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscriminator.html 
>>  On 26.02.2010 08:21, Achim Wiedemann wrote:
>>> Hey everybody,
>>>
>>> just wanted to port our application from commons-logging / log4j to
>>> slf4j / logback. Unfortunately I stumbled upon some problems when
>>> separating the logging-output from different webapps (using the
>>> JNDIContextSelector). As long as you only use logging from classes
>>> inside the webapp, everything works fine. But as soon as you've got
>>> classes in tomcat/shared which use logging, you run into trouble:  
>>> All
>>> logging output of the shared classes (e.g. Spring) are directed to  
>>> the
>>> logger-context of the webapp which first loads the (shared) class.
>>>
>>> Example: Let's say you've got webbapp [A], webbapp [B], and Spring  
>>> in
>>> tomcat/shared. Now both webapps use Spring. If webapp [B] first  
>>> accesses
>>> any classes of Spring, all output of Spring will be directed to the
>>> log-file of [B], no matter from which webapp Spring is used. This is
>>> because static Logger references are used in Spring (which is
>>> commonplace) and are initialized with the context of webapp [B].
>>>
>>> The issue is already described very well in the logback JIRA:
>>> http://jira.qos.ch/browse/LBCLASSIC-166
>>>
>>> I wondered if anyone can make a suggestion how to deal with this.  
>>> Any
>>> advice, tricks or magic is welcome. ;)
>>>
>>>
>>> Thanks a lot,
>>> Achim
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://qos.ch/mailman/listinfo/logback-user
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user


More information about the Logback-user mailing list