This is not something that can or should be automated imho. ThreadContext data 
disappearing automatically can be just as confusing to troubleshoot (or more 
so). 

Remko

> On Apr 19, 2018, at 2:40, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> On Tue, Apr 17, 2018 at 10:22 AM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
>> I have mixed feelings about that. Every filter I have created that clears
>> the ThreadContext at the end also injects values into the ThreadContext at
>> the beginning of the request, just as the example at
>> http://logging.apache.org/log4j/2.x/manual/eventlogging.html <
>> http://logging.apache.org/log4j/2.x/manual/eventlogging.html> does. So if
>> you were going to create a filter you would also want to provide a method
>> to do the setup, so your filter code would look something like:
>> 
>> public void doFilter(ServletRequest servletRequest, ServletResponse
>> servletResponse, FilterChain filterChain throws IOException,
>> ServletException {
>>        setupRequest(servletRequest, servletResponse);
>>        filterChain.doFilter(servletRequest, servletResponse);
>>        ThreadContext.clear();
>> }
>> 
>> public void setupRequest(servletRequest, servletResponse) {
>> }
>> 
>> But the only value this really has is the one line that was added to clear
>> the ThreadContext.  Is that really much of a “convenience”?
>> 
> 
> If that saves me the 30 minutes to Google, filter, understand, copy, and
> paste, then yes it is worth it.
> 
> Gary
> 
> 
>> 
>> Ralph
>> 
>> 
>>> On Apr 17, 2018, at 6:29 AM, Gary Gregory <garydgreg...@gmail.com>
>> wrote:
>>> 
>>> Should we provide a stock Log4j filter that does that? A nice
>> convenience.
>>> 
>>> Gary
>>> 
>>> On Mon, Apr 16, 2018 at 10:01 PM, Kevin Jung <mykevinj...@gmail.com>
>> wrote:
>>> 
>>>> Thanks Remko and Ralph for the information.  I thought of clearing in a
>>>> filter, but somehow I thought there might be a clean up mechanism
>> already
>>>> because using ThreadContext in Tomcat is a quite common thing.  But that
>>>> was just my assumption.  I agree that it's better to *clear explicitly*.
>>>> 
>>>> Thanks,
>>>> Kevin
>>>> 
>>>> On Mon, Apr 16, 2018 at 8:32 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>>>> wrote:
>>>> 
>>>>> See the example at http://logging.apache.org/
>>>>> log4j/2.x/manual/eventlogging.html <http://logging.apache.org/
>>>>> log4j/2.x/manual/eventlogging.html>. You will see the call to clear
>> the
>>>>> ThreadContext. It does indeed use a filter.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Apr 16, 2018, at 7:01 PM, Kevin Jung <mykevinj...@gmail.com>
>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I am using Log4j 2 ThreadContext with Tomcat.  I wonder if I need to
>>>>> clear
>>>>>> ThreadContext at the end (or start) of HTTP request in order to avoid
>>>> the
>>>>>> context data being carried over to next HTTP request processing.
>>>>>> 
>>>>>> I was assuming that thread context is cleared when Tomcat thread is
>> put
>>>>>> back in the thread pool and when a Tomcat thread starts processing new
>>>>> HTTP
>>>>>> request, it starts with an empty thread context, nothing carried over
>>>>> from
>>>>>> the previous HTTP request.  But that's my assumption, I want to make
>>>>> sure I
>>>>>> do not need to clear at the end, like using a servlet filter.  Or
>>>> should
>>>>> I
>>>>>> use CloseableThreadContext to avoid carrying over among HTTP requests?
>>>>>> 
>>>>>> Thanks,
>>>>>> Kevin
>>>>> 
>>>>> 
>>>> 
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Reply via email to