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>