You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/01/18 05:17:17 UTC
Question about Log4jServletFilter in core.
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 <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Scott Deboy <sc...@gmail.com>.
+1 for a minimal jar with the servlet support.
On Jan 18, 2014 9:36 AM, "Ralph Goers" <ra...@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 <ni...@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 <bo...@gmail.com>
>
>
>
>
Re: Question about Log4jServletFilter in core.
Posted by Matt Sicker <bo...@gmail.com>.
An instance of Log4jWebInitializer is stored in the servlet context, but
that's a package-private interface since it's only used internally
in org.apache.logging.log4j.core.web.
On 18 January 2014 17:50, Nick Williams <ni...@nicholaswilliams.net>wrote:
> I don't think that's necessary. The logger context definitely is already
> added to the Servlet context attributes. It's adding it to each request's
> attributes in the filter that's needed, if I remember the code correctly.
> I'm not in a position to look at it right now.
>
> N
>
>
> On Jan 18, 2014, at 3:43 PM, Matt Sicker wrote:
>
> I'm currently working on a patch that stores the logger context instance
> in the servlet context attribute named
> "org.apache.logging.log4j.spi.LoggerContext.ctx" (you can probably guess
> how that comes into being). It's a bit of a modification from the attached
> patch on LOG4J2-452 as I've also addressed some abuse of the
> synchronization keyword issues as well. I should be done with this patch
> within the next few hours.
>
>
> On 18 January 2014 17:13, Nick Williams <ni...@nicholaswilliams.net>wrote:
>
>>
>> On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote:
>>
>> I somewhat figured that anyone who would be using advanced async servlets
>> probably isn't doing it in just a servlet container. I'd expect that sort
>> of thing in an application container which does allow for some added
>> abilities and such. Hence why OSGi came to mind. I know that WebSphere uses
>> something vaguely similar to OSGi called "features", and like you said,
>> JBoss/WildFly is using OSGi internally to some extent. Web Logic (at least
>> the older 10.3 version we use at Peapod) just sort of barfs JARs and WARs
>> all over the place and depends on archaic shell scripts to manage
>> everything.
>>
>> Well anyway, in regard to some of your concerns about servlet 3.0,
>> version 3.1 addressed some of these issues. For one, servlet and filter
>> initialization was updated:
>>
>> >The service method is required to run in the same thread as all filters
>> that apply to
>> >the servlet.
>>
>> So that takes care of that! Developers who write multi-threaded servlets
>> (which sounds awesome and terrible at the same time; thought this was the
>> point of things like EJB and CDI) will have to fetch the logger context
>> from, well, there's nowhere it's being stored that's easily obtained by the
>> servlet writer. I'd put it in the request object as a wrapper in the filter.
>>
>>
>> Good point. I can certainly make sure that the context is available as a
>> request attribute. We can then publish that in the documentation for others
>> to consume.
>>
>> Someone mentioned elsewhere about intercepting reads or writes on the
>> servlet request or response objects in an async context, and v3.1 added
>> javax.servlet.ReadListener and javax.servlet.WriteListener for just that
>> situation.
>>
>>
>> No, that does us no good. That lets us know that someone called a write()
>> method on the output stream or a read() method on the input stream. So
>> what? That doesn't empower us to do anything. The user doesn't need us to
>> log those events. The user needs us to set up the logging context so that
>> they can log things. What we would need is a way to detect that they were
>> running a separate thread that was eventually going to call write() or
>> read(), set the context in that thread, and then detect when they were done
>> with the thread (probably returning it to a thread pool). Doing this would
>> be vastly complicated (if even possible) on a container-by-container basis,
>> impossible using the generic API. I contend that we simply can't do it.
>> Users of Log4j who write asynchronous request handling will have to know to
>> set the logging context (if necessary) in extrarequest threads. The best we
>> can do is strongly document that requirement—which I will do.
>>
>> Nick
>>
>>
>>
>> On 18 January 2014 16:10, Nicholas Williams <
>> nicholas@nicholaswilliams.net> wrote:
>>
>>> 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 <bo...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@gmail.com>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
I don't think that's necessary. The logger context definitely is already added to the Servlet context attributes. It's adding it to each request's attributes in the filter that's needed, if I remember the code correctly. I'm not in a position to look at it right now.
N
On Jan 18, 2014, at 3:43 PM, Matt Sicker wrote:
> I'm currently working on a patch that stores the logger context instance in the servlet context attribute named "org.apache.logging.log4j.spi.LoggerContext.ctx" (you can probably guess how that comes into being). It's a bit of a modification from the attached patch on LOG4J2-452 as I've also addressed some abuse of the synchronization keyword issues as well. I should be done with this patch within the next few hours.
>
>
> On 18 January 2014 17:13, Nick Williams <ni...@nicholaswilliams.net> wrote:
>
> On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote:
>
>> I somewhat figured that anyone who would be using advanced async servlets probably isn't doing it in just a servlet container. I'd expect that sort of thing in an application container which does allow for some added abilities and such. Hence why OSGi came to mind. I know that WebSphere uses something vaguely similar to OSGi called "features", and like you said, JBoss/WildFly is using OSGi internally to some extent. Web Logic (at least the older 10.3 version we use at Peapod) just sort of barfs JARs and WARs all over the place and depends on archaic shell scripts to manage everything.
>>
>> Well anyway, in regard to some of your concerns about servlet 3.0, version 3.1 addressed some of these issues. For one, servlet and filter initialization was updated:
>>
>> >The service method is required to run in the same thread as all filters that apply to
>> >the servlet.
>>
>> So that takes care of that! Developers who write multi-threaded servlets (which sounds awesome and terrible at the same time; thought this was the point of things like EJB and CDI) will have to fetch the logger context from, well, there's nowhere it's being stored that's easily obtained by the servlet writer. I'd put it in the request object as a wrapper in the filter.
>
> Good point. I can certainly make sure that the context is available as a request attribute. We can then publish that in the documentation for others to consume.
>
>> Someone mentioned elsewhere about intercepting reads or writes on the servlet request or response objects in an async context, and v3.1 added javax.servlet.ReadListener and javax.servlet.WriteListener for just that situation.
>
> No, that does us no good. That lets us know that someone called a write() method on the output stream or a read() method on the input stream. So what? That doesn't empower us to do anything. The user doesn't need us to log those events. The user needs us to set up the logging context so that they can log things. What we would need is a way to detect that they were running a separate thread that was eventually going to call write() or read(), set the context in that thread, and then detect when they were done with the thread (probably returning it to a thread pool). Doing this would be vastly complicated (if even possible) on a container-by-container basis, impossible using the generic API. I contend that we simply can't do it. Users of Log4j who write asynchronous request handling will have to know to set the logging context (if necessary) in extrarequest threads. The best we can do is strongly document that requirement—which I will do.
>
> Nick
>
>>
>>
>> On 18 January 2014 16:10, Nicholas Williams <ni...@nicholaswilliams.net> wrote:
>> 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 <bo...@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 <ra...@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 <ni...@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 <ga...@gmail.com> wrote:
>>>>
>>>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Matt Sicker <bo...@gmail.com>.
I'm currently working on a patch that stores the logger context instance in
the servlet context attribute named
"org.apache.logging.log4j.spi.LoggerContext.ctx" (you can probably guess
how that comes into being). It's a bit of a modification from the attached
patch on LOG4J2-452 as I've also addressed some abuse of the
synchronization keyword issues as well. I should be done with this patch
within the next few hours.
On 18 January 2014 17:13, Nick Williams <ni...@nicholaswilliams.net>wrote:
>
> On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote:
>
> I somewhat figured that anyone who would be using advanced async servlets
> probably isn't doing it in just a servlet container. I'd expect that sort
> of thing in an application container which does allow for some added
> abilities and such. Hence why OSGi came to mind. I know that WebSphere uses
> something vaguely similar to OSGi called "features", and like you said,
> JBoss/WildFly is using OSGi internally to some extent. Web Logic (at least
> the older 10.3 version we use at Peapod) just sort of barfs JARs and WARs
> all over the place and depends on archaic shell scripts to manage
> everything.
>
> Well anyway, in regard to some of your concerns about servlet 3.0, version
> 3.1 addressed some of these issues. For one, servlet and filter
> initialization was updated:
>
> >The service method is required to run in the same thread as all filters
> that apply to
> >the servlet.
>
> So that takes care of that! Developers who write multi-threaded servlets
> (which sounds awesome and terrible at the same time; thought this was the
> point of things like EJB and CDI) will have to fetch the logger context
> from, well, there's nowhere it's being stored that's easily obtained by the
> servlet writer. I'd put it in the request object as a wrapper in the filter.
>
>
> Good point. I can certainly make sure that the context is available as a
> request attribute. We can then publish that in the documentation for others
> to consume.
>
> Someone mentioned elsewhere about intercepting reads or writes on the
> servlet request or response objects in an async context, and v3.1 added
> javax.servlet.ReadListener and javax.servlet.WriteListener for just that
> situation.
>
>
> No, that does us no good. That lets us know that someone called a write()
> method on the output stream or a read() method on the input stream. So
> what? That doesn't empower us to do anything. The user doesn't need us to
> log those events. The user needs us to set up the logging context so that
> they can log things. What we would need is a way to detect that they were
> running a separate thread that was eventually going to call write() or
> read(), set the context in that thread, and then detect when they were done
> with the thread (probably returning it to a thread pool). Doing this would
> be vastly complicated (if even possible) on a container-by-container basis,
> impossible using the generic API. I contend that we simply can't do it.
> Users of Log4j who write asynchronous request handling will have to know to
> set the logging context (if necessary) in extrarequest threads. The best we
> can do is strongly document that requirement—which I will do.
>
> Nick
>
>
>
> On 18 January 2014 16:10, Nicholas Williams <nicholas@nicholaswilliams.net
> > wrote:
>
>> 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 <bo...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Jan 18, 2014, at 2:42 PM, Matt Sicker wrote:
> I somewhat figured that anyone who would be using advanced async servlets probably isn't doing it in just a servlet container. I'd expect that sort of thing in an application container which does allow for some added abilities and such. Hence why OSGi came to mind. I know that WebSphere uses something vaguely similar to OSGi called "features", and like you said, JBoss/WildFly is using OSGi internally to some extent. Web Logic (at least the older 10.3 version we use at Peapod) just sort of barfs JARs and WARs all over the place and depends on archaic shell scripts to manage everything.
>
> Well anyway, in regard to some of your concerns about servlet 3.0, version 3.1 addressed some of these issues. For one, servlet and filter initialization was updated:
>
> >The service method is required to run in the same thread as all filters that apply to
> >the servlet.
>
> So that takes care of that! Developers who write multi-threaded servlets (which sounds awesome and terrible at the same time; thought this was the point of things like EJB and CDI) will have to fetch the logger context from, well, there's nowhere it's being stored that's easily obtained by the servlet writer. I'd put it in the request object as a wrapper in the filter.
Good point. I can certainly make sure that the context is available as a request attribute. We can then publish that in the documentation for others to consume.
> Someone mentioned elsewhere about intercepting reads or writes on the servlet request or response objects in an async context, and v3.1 added javax.servlet.ReadListener and javax.servlet.WriteListener for just that situation.
No, that does us no good. That lets us know that someone called a write() method on the output stream or a read() method on the input stream. So what? That doesn't empower us to do anything. The user doesn't need us to log those events. The user needs us to set up the logging context so that they can log things. What we would need is a way to detect that they were running a separate thread that was eventually going to call write() or read(), set the context in that thread, and then detect when they were done with the thread (probably returning it to a thread pool). Doing this would be vastly complicated (if even possible) on a container-by-container basis, impossible using the generic API. I contend that we simply can't do it. Users of Log4j who write asynchronous request handling will have to know to set the logging context (if necessary) in extrarequest threads. The best we can do is strongly document that requirement—which I will do.
Nick
>
>
> On 18 January 2014 16:10, Nicholas Williams <ni...@nicholaswilliams.net> wrote:
> 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 <bo...@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 <ra...@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 <ni...@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 <ga...@gmail.com> wrote:
>>>
>>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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 <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Matt Sicker <bo...@gmail.com>.
I somewhat figured that anyone who would be using advanced async servlets
probably isn't doing it in just a servlet container. I'd expect that sort
of thing in an application container which does allow for some added
abilities and such. Hence why OSGi came to mind. I know that WebSphere uses
something vaguely similar to OSGi called "features", and like you said,
JBoss/WildFly is using OSGi internally to some extent. Web Logic (at least
the older 10.3 version we use at Peapod) just sort of barfs JARs and WARs
all over the place and depends on archaic shell scripts to manage
everything.
Well anyway, in regard to some of your concerns about servlet 3.0, version
3.1 addressed some of these issues. For one, servlet and filter
initialization was updated:
>The service method is required to run in the same thread as all filters
that apply to
>the servlet.
So that takes care of that! Developers who write multi-threaded servlets
(which sounds awesome and terrible at the same time; thought this was the
point of things like EJB and CDI) will have to fetch the logger context
from, well, there's nowhere it's being stored that's easily obtained by the
servlet writer. I'd put it in the request object as a wrapper in the filter.
Someone mentioned elsewhere about intercepting reads or writes on the
servlet request or response objects in an async context, and v3.1 added
javax.servlet.ReadListener and javax.servlet.WriteListener for just that
situation.
On 18 January 2014 16:10, Nicholas Williams
<ni...@nicholaswilliams.net>wrote:
> 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 <bo...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Nicholas Williams <ni...@nicholaswilliams.net>.
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 <bo...@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 <ra...@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 <ni...@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 <ga...@gmail.com> wrote:
>>>>
>>>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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 <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Gary Gregory <ga...@gmail.com>.
It might be interesting to see how Eclipse and Jetty play together.
Gary
On Sat, Jan 18, 2014 at 5:07 PM, Ralph Goers <ra...@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 <bo...@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 <ra...@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 <ga...@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 <bo...@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 <bo...@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
Re: Question about Log4jServletFilter in core.
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@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 <ra...@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 <ni...@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 <ga...@gmail.com> wrote:
>>
>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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 <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@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 <ga...@gmail.com> wrote:
>
> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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 <bo...@gmail.com>
Re: Question about Log4jServletFilter in core.
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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 <ga...@gmail.com> wrote:
>
>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
Re: logging to solr/elasticsearch
Posted by Matt Sicker <bo...@gmail.com>.
The closest existing components that are vaguely related to what you're
requesting are Mongo and CouchDB appenders. In log4j-core, the NoSQL
appenders might be a good place to put this, but I'm not too sure. I mean,
solr is kind of like a database, so it might belong in db at least.
On 26 January 2014 16:10, Markus Klose <lo...@markus-klose.de> wrote:
> Hello everyone,
>
>
> last thursday i had a small chat with christian grobmeier on a java user
> group meeting
> i am doing a lot of search and analytics in my daily business and i am
> very interessted in developing a component that directly logs into a
> solr/elasticsearch index
>
> Over a year ago i allready did some development on a solr appender
> if you are interesetedyou can have a look at :
> http://sourceforge.net/projects/log4jsolr.slugdev.p/
>
> I like to develop a new component for log4j 2
>
> My questions to you
> - is there allready done or planned in that direction?
> - where would such a component would fits best to log2j? (appender?
> plugin?)
> - whats the best way to configure an "appender"? in my first versionof
> the solr appender i had a lot of optional field mapping whicht made the
> configuration within the log4j.xml quite big
>
> would be great to get some feedback.
> this could be a good way to connect log events directly to a tool like
> kibana
>
> regards
> Markus Klose
>
>
>
--
Matt Sicker <bo...@gmail.com>
logging to solr/elasticsearch
Posted by Markus Klose <lo...@markus-klose.de>.
Hello everyone,
last thursday i had a small chat with christian grobmeier on a java user group
meeting
i am doing a lot of search and analytics in my daily business and i am very
interessted in developing a component that directly logs into a
solr/elasticsearch index
Over a year ago i allready did some development on a solr appender
if you are interesetedyou can have a look at
:http://sourceforge.net/projects/log4jsolr.slugdev.p/
I like to develop a new component for log4j 2
My questions to you
- is there allready done or planned in that direction?
- where would such a component would fits best to log2j? (appender? plugin?)
- whats the best way to configure an "appender"? in my first versionof the solr
appender i had a lot of optional field mapping whicht made the configuration
within the log4j.xml quite big
would be great to get some feedback.
this could be a good way to connect log events directly to a tool like kibana
regards
Markus Klose
Re: Question about Log4jServletFilter in core.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@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 <ga...@gmail.com> wrote:
>>
>>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
>
Re: Question about Log4jServletFilter in core.
Posted by Ralph Goers <ra...@dslextreme.com>.
Nick, Are you working on this?
Ralph
On Jan 18, 2014, at 11:38 AM, Nicholas Williams <ni...@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 <ga...@gmail.com> wrote:
>
>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
Re: Question about Log4jServletFilter in core.
Posted by Nicholas Williams <ni...@nicholaswilliams.net>.
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 <ga...@gmail.com> wrote:
>
>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
Re: Question about Log4jServletFilter in core.
Posted by Ralph Goers <ra...@dslextreme.com>.
See http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContainerInitializer.html. We are providing a service definition in META-INF/services/javax.servlet.ServiceContainerInitializer. Once that is found the servlet container is supposed to invoke the initializer. However there are some problems with this as there is no guaranteed order for running them. I suppose the ServletContext could be inspected to look for a setting to disable it. Perhaps if there is no log4j configuration file we could also ignore it.
One thing I really don’t like is that the initializer also throws an error if it finds a manually configured servlet context listener. To me, this is exactly backwards. If the servlet context listener is configured that should take precedence over the initializer.
Ralph
On Jan 18, 2014, at 10:54 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
Re: Question about Log4jServletFilter in core.
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers <ra...@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 <ni...@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 <bo...@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
Re: Question about Log4jServletFilter in core.
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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 <bo...@gmail.com>
>
Re: Question about Log4jServletFilter in core.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <bo...@gmail.com>