Unfortunately, Log4j simply has no way to guarantee intercepting when an asynchronous request "wakes up." If the code dispatches the async context to another Servlet or to a JSP, it'll trigger the Log4j filter again. If the code just writes to the output stream, there's no way to know that happened.
A filter isn't the "perfect" solution, but it's really our only choice. It takes care of _most_ situations—the vast majority of situations, I would argue. Developers who use async contexts will have to go to extra effort to make sure the logging context is set up. I don't see any way to avoid that. Removing the filter would make life more difficult for those devs using non-asynchronous requests. On the up side, not only does this issue only affect devs using async requests, but also of THOSE situations it only really makes an impact with non-standard configurations. Typical "out of the box" configurations don't really NEED the logging context set up on each request. N Sent from my iPhone from LAX baggage claim, so please forgive brief replies and frequent typos > On Jan 18, 2014, at 13:56, Matt Sicker <boa...@gmail.com> wrote: > > Guys, I've been reading a little bit about OSGi lately, and that seems like > the perfect use case when combined with servlet 3.0. The thing is, making > minimal JARs is a lot like making bundles. > > The issue I see with async servlets, though, is how to manage the thread > local logger context when an async servlet can have multiple threads. The > most trivial way to make the proper logger context available _somewhere_ is > using request attributes or the servlet context attributes (which is already > being used to hold the initializer which holds the logger context anyway). > That's the thing, though. With multiple threads in a single web app instance, > it's hard to manage state for all those threads without being higher up in > the food chain. I don't think implementing this as a filter is the best way > to go for servlet 3.0. > > >> On 18 January 2014 15:19, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> I was hoping to start the GA release sooner than that. >> >> If the servlet context initializer is disabled then the listener should >> still be allowed. >> >> Ralph >> >>> On Jan 18, 2014, at 11:38 AM, Nicholas Williams >>> <nicho...@nicholaswilliams.net> wrote: >>> >>> Yes. Next weekend I plan on adding a Servlet context parameter that allows >>> the user to disable starting Log4j automatically. That should allow us to >>> keep everything in one JAR while supporting both sides of the argument. >>> >>> Nick >>> >>> Sent from my iPhone, so please forgive brief replies and frequent typos >>> >>>> On Jan 18, 2014, at 10:54, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers >>>>> <ralph.go...@dslextreme.com> wrote: >>>>> I’ve always had reservations about the servlet 3.0 automatic >>>>> configuration because if the log4j jar is present it can’t be disabled or >>>>> be modified by the end user. We’ve had some issues with Spring >>>>> initialization and now LOG4J2-452 reinforces that. I would propose that >>>>> if we want to keep it that we move the minimum amount required into its >>>>> own jar so that users have a choice as to whether it is automatically >>>>> initialized. >>>>> >>>>> Am I the only one who feels this way? Frankly, this and one other issue >>>>> I plan to work on this weekend are the only things I see as blockers for >>>>> a GA release. >>>> >>>> For me, the fewer jars, the better. Can't this be configured somehow >>>> without having to do more jar juggling? >>>> >>>> Gary >>>> >>>>> >>>>> Ralph >>>>> >>>>>> On Jan 17, 2014, at 8:25 PM, Nick Williams >>>>>> <nicho...@nicholaswilliams.net> wrote: >>>>>> >>>>>> Filter initialization is one of the last things to happen in web app >>>>>> startup. The ServletContainerInitializer sets the threads logger context >>>>>> so that web app startup procedures can use it. The filter's init() >>>>>> method clears it near the end of startup so that it doesn't bleed into >>>>>> another web app. >>>>>> >>>>>> Then, on web apps shutdown, destruction of filters is one of the first >>>>>> things to happen. The filter's destroy() sets the logger context so that >>>>>> the web app shutdown procedures can use it. >>>>>> >>>>>> Nick >>>>>> >>>>>>> On Jan 17, 2014, at 10:17 PM, Matt Sicker wrote: >>>>>>> >>>>>>> Now I'm not sure if I'm interpreting this correctly, but init() clears >>>>>>> the current thread's logger context, and destroy() sets it. What's up >>>>>>> with this? Especially since it just gets set and cleared in the >>>>>>> doFilter() bit. >>>>>>> >>>>>>> -- >>>>>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> Java Persistence with Hibernate, Second Edition >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <boa...@gmail.com>
