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>
