You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/07/13 23:56:52 UTC
Question about the ContextAnchor class in log4j-core.
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 <bo...@gmail.com>
Re: Question about the ContextAnchor class in log4j-core.
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@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 <ra...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Question about the ContextAnchor class in log4j-core.
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <ra...@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 <bo...@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 <bo...@gmail.com>
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Question about the ContextAnchor class in log4j-core.
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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 <bo...@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 <bo...@gmail.com>
>
Re: Question about the ContextAnchor class in log4j-core.
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <bo...@gmail.com>