[logback-user] Separating the logging-output of libraries in tomcat/shared
awn at inxmail.de
Tue Mar 2 07:52:36 CET 2010
Dear Robert and Ceki,
thanks for your replies. I'll check out your suggestions as soon as I
can get to it. Of course, I'll let you know how things turned out. :)
Ceki Gülcü schrieb:
> You are right. ContextBasedDiscriminator will not help you because the
> context name is retreived from the LoggingEvent which ultimately gets
> its value from the calling logger. If the calling logger is attached to
> the wrong context, ContextBasedDiscriminator will give you the wrong
> context name. Sorry for misleading you.
> However, I've written a new discriminator which should work assuming you
> have installed ContextJNDISelector as explained in
> JNDIBasedContextDiscriminator can be found at
> or the same in tiny-speak
> Getting values from JNDIBasedContextDiscriminator, SiftingAppender will
> get the correct context name and things should work much better. Give it
> a try.
> On 01/03/2010 9:38 AM, Achim Wiedemann 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.
>> 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  using the context as separation criteria . 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.
>>>  http://logback.qos.ch/manual/appenders.html#SiftingAppender
>>> 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
>>>> 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:
>>>> I wondered if anyone can make a suggestion how to deal with this. Any
>>>> advice, tricks or magic is welcome. ;)
>>>> Thanks a lot,
>>> Logback-user mailing list
>>> Logback-user at qos.ch
>> Logback-user mailing list
>> Logback-user at qos.ch
> Logback-user mailing list
> Logback-user at qos.ch
More information about the Logback-user