I don't think that's necessary. The logger context definitely is already added to the Servlet context attributes. It's adding it to each request's attributes in the filter that's needed, if I remember the code correctly. I'm not in a position to look at it right now.
N On Jan 18, 2014, at 3:43 PM, Matt Sicker wrote: > I'm currently working on a patch that stores the logger context instance in > the servlet context attribute named > "org.apache.logging.log4j.spi.LoggerContext.ctx" (you can probably guess how > that comes into being). It's a bit of a modification from the attached patch > on LOG4J2-452 as I've also addressed some abuse of the synchronization > keyword issues as well. I should be done with this patch within the next few > hours. > > > On 18 January 2014 17:13, Nick Williams <nicho...@nicholaswilliams.net> wrote: > > On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote: > >> I somewhat figured that anyone who would be using advanced async servlets >> probably isn't doing it in just a servlet container. I'd expect that sort of >> thing in an application container which does allow for some added abilities >> and such. Hence why OSGi came to mind. I know that WebSphere uses something >> vaguely similar to OSGi called "features", and like you said, JBoss/WildFly >> is using OSGi internally to some extent. Web Logic (at least the older 10.3 >> version we use at Peapod) just sort of barfs JARs and WARs all over the >> place and depends on archaic shell scripts to manage everything. >> >> Well anyway, in regard to some of your concerns about servlet 3.0, version >> 3.1 addressed some of these issues. For one, servlet and filter >> initialization was updated: >> >> >The service method is required to run in the same thread as all filters >> >that apply to >> >the servlet. >> >> So that takes care of that! Developers who write multi-threaded servlets >> (which sounds awesome and terrible at the same time; thought this was the >> point of things like EJB and CDI) will have to fetch the logger context >> from, well, there's nowhere it's being stored that's easily obtained by the >> servlet writer. I'd put it in the request object as a wrapper in the filter. > > Good point. I can certainly make sure that the context is available as a > request attribute. We can then publish that in the documentation for others > to consume. > >> Someone mentioned elsewhere about intercepting reads or writes on the >> servlet request or response objects in an async context, and v3.1 added >> javax.servlet.ReadListener and javax.servlet.WriteListener for just that >> situation. > > No, that does us no good. That lets us know that someone called a write() > method on the output stream or a read() method on the input stream. So what? > That doesn't empower us to do anything. The user doesn't need us to log those > events. The user needs us to set up the logging context so that they can log > things. What we would need is a way to detect that they were running a > separate thread that was eventually going to call write() or read(), set the > context in that thread, and then detect when they were done with the thread > (probably returning it to a thread pool). Doing this would be vastly > complicated (if even possible) on a container-by-container basis, impossible > using the generic API. I contend that we simply can't do it. Users of Log4j > who write asynchronous request handling will have to know to set the logging > context (if necessary) in extrarequest threads. The best we can do is > strongly document that requirement—which I will do. > > Nick > >> >> >> On 18 January 2014 16:10, Nicholas Williams <nicho...@nicholaswilliams.net> >> wrote: >> 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> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> > > > > > -- > Matt Sicker <boa...@gmail.com>
