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. 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. 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>
