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

Ceki Gülcü ceki at qos.ch
Mon Mar 1 19:29:19 CET 2010


In my opinion, the current thread class loader is too low level to be of use. 
Retrieving values from JNDI is a bit safer (we don't have to keep around 
references to class loaders) and also allows us set/get context names.

On 01/03/2010 2:00 PM, Robert Elliot wrote:
> 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
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user



More information about the Logback-user mailing list