logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Question about Log4jServletFilter in core.
Date Sun, 19 Jan 2014 04:54:00 GMT
It might be interesting to see how Eclipse and Jetty play together.

Gary


On Sat, Jan 18, 2014 at 5:07 PM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> Well, I’ve always had issues with mixing the servlet spec and OSGi.
>  Having OSGi run in the servlet container is just awkward, and I don’t know
> how of anybody really running the servlet container inside of OSGi.  I know
> the latest versions of JBoss are doing something OSGi-like, but I’m not
> aware that it provides real OSGi support.
>
> The servlet spec doesn’t really give us anywhere else to hook into other
> than a filter or initializer. Hooking above that and you have to create a
> custom implementation for each container - if it allows that.
>
> Ralph
>
>
> On Jan 18, 2014, at 1:56 PM, 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<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 <boards@gmail.com>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
View raw message