logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Williams <nicho...@nicholaswilliams.net>
Subject Re: Question about Log4jServletFilter in core.
Date Sat, 18 Jan 2014 22:10:15 GMT
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 <boards@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.goers@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 <nicholas@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 <garydgregory@gmail.com> wrote:
>>>> 
>>>>> On Sat, Jan 18, 2014 at 12:35 PM, 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.
>>>> 
>>>> 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 <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>
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> E-Mail: garydgregory@gmail.com | ggregory@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 <boards@gmail.com>

Mime
View raw message