logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Deboy <scott.de...@gmail.com>
Subject Re: Question about Log4jServletFilter in core.
Date Sat, 18 Jan 2014 17:53:25 GMT
+1 for a minimal jar with the servlet support.
On Jan 18, 2014 9:36 AM, "Ralph Goers" <ralph.goers@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.
> Ralph
> On Jan 17, 2014, at 8:25 PM, Nick Williams <nicholas@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 <boards@gmail.com>

View raw message