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>
