Agreed. I don't think we need a separate filter from log4j2. People may already have filters and just need to add one line there; or can create one easily if they don't have.
But I think it's good to mention somewhere, probably on https://logging.apache.org/log4j/2.x/manual/thread-context.html that thread context needs to be cleared to avoid being carried over to the next run when thread context is used in a thread pool, e.g. Tomcat thread pool or Camel thread pool. If the document gives a sample filter, it would be more helpful. On Wed, Apr 18, 2018 at 3:30 PM, Remko Popma <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > On Tue, Apr 17, 2018 at 10:22 AM, Ralph Goers < > [email protected]> > > 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 <[email protected]> > >> 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 <[email protected]> > >> 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 < > >> [email protected]> > >>>> 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 <[email protected]> > >> 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: [email protected] > For additional commands, e-mail: [email protected] > >
