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 > > > > >
