logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: Question about Log4jServletFilter in core.
Date Sun, 26 Jan 2014 22:31:03 GMT
I am. Today, in fact.

N

On Jan 26, 2014, at 3:43 PM, Ralph Goers wrote:

> Nick, Are you working on this?
> 
> 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
> 


Mime
View raw message