+1 for a minimal jar with the servlet support. On Jan 18, 2014 9:36 AM, "Ralph Goers" <[email protected]> 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. > > Ralph > > On Jan 17, 2014, at 8:25 PM, Nick Williams <[email protected]> > 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 <[email protected]> > > > >
