[logback-user] Context selectors useful?

[Lars Ködderitzsch]

Hello Ceki,

> Switching log files can be accomplished by a new appender which can embed and 
> manage appenders based on MDC values.
This sounds like a vialable way, that somehow matches my current log4j 
based hack. Is this appender already available?
I had a quick look at the 0.9.11 sources and didn't find any.

> Additional detail would be nice. For example, how are you managing thread local 
> values in the web-app and in ejbs?
For web-apps I currently use a servlet filter, which sets a thread 
special thread local variable to the value of a special context param in 
the webapp.
This matches the MDC approach using servlet filters.

For ejb's this proves a bit more difficult (at least EJB2, havent checke 
EJB3 so far) since there is no standardized support for custom EJB 
interceptors.
Currently I am using aspectj to weave an aspect around the ejb 
implementation class - which sets the thread local.

A third use case are workmanager and timer threads (Websphere 6.1), 
where the aspect aproach also works - here the context setting aspect is 
applied the work item implementation classes (basically a Runnable 
implementation).


I'll answer separately on your other, most recent mail.

Regards,
Lars





Ceki Gulcu schrieb:
> Lars Ködderitzsch wrote:
>   
>> Hello Ceki,
>>
>> thanks for the heads up on this issue on the mailing list.
>>
>> Starting off I'd like to mention that for me the most wanted feature is
>> separation of logging from different contexts (e.g. war's, ejb) of of an
>> enterprise application (ear), without needing to resort to classloader
>> stunts, multiple repeated logging configurations etc.
>>     
>
>   
>> That means that the contexts of an enterprise app should be able to use
>> the same logging implementation (that is placed in the ear classloader)
>> and the same logging configuration, but ultimately the log into
>> different log files.
>> This way it can be truely sorted out, which context logged which message.
>>
>> To my knowledge such a thing is supported in neither logging
>> implementations.
>> Currently I am running this as a hack on log4j, based on a specialized
>> appender which switches the underlying log file based on some thread
>> local, which in turn is set by a special servlet filter in each web context.
>>     
>> If your're interested I can elaborate more on the problem, so you can
>> get a better understanding what would actually be needed.
>>