An instance of Log4jWebInitializer is stored in the servlet context, but that's a package-private interface since it's only used internally in org.apache.logging.log4j.core.web.
On 18 January 2014 17:50, Nick Williams <nicho...@nicholaswilliams.net>wrote: > 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<http://www.manning.com/bauer3/> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>> Spring Batch in Action <http://www.manning.com/templier/> >>>> 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> > > > -- Matt Sicker <boa...@gmail.com>
