logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Question about the ContextAnchor class in log4j-core.
Date Sun, 20 Jul 2014 02:31:53 GMT
All my concerns were addressed in a recent update to log4j-web that added
some handy utility methods.


On 13 July 2014 19:22, Matt Sicker <boards@gmail.com> wrote:

> I'm just looking for a way to make this easier to use in async servlets.
> I've been implementing some at work lately as an experimental way of
> creating a REST facade for a JMS-based service, and having an easier method
> to obtaining the right Logger would be nice.
>
>
> On 13 July 2014 17:16, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>
>> Oh - and the main purpose of the ContextAnchor is to reduce the overhead
>> of finding the current LoggerContext.
>>
>> Anyone using asynchronous servlets would probably need to copy the
>> ThreadContextMap as well as the ContextAnchor for the new Thread.
>>
>> Ralph
>>
>> On Jul 13, 2014, at 3:12 PM, Ralph Goers <ralph.goers@dslextreme.com>
>> wrote:
>>
>> What guarantee do you have that the asynchronous servlet is in a child
>> thread?  ThreadContextMap was originally an InheritableThreadLocal but had
>> to be changed to a ThreadLocal due to the problems automatic inheritance
>> causes.
>>
>> Ralph
>>
>> On Jul 13, 2014, at 2:56 PM, Matt Sicker <boards@gmail.com> wrote:
>>
>> The main purpose of this class is to keep a ThreadLocal<LoggerContext>
>> variable for keeping track of LoggerContexts. Would it make sense to use
>> InheritableThreadLocal instead? This way the current thread's LoggerContext
>> is preserved for new threads in a situation such as asynchronous servlets.
>>
>> --
>> Matt Sicker <boards@gmail.com>
>>
>>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message