logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Next release
Date Sun, 13 Jul 2014 20:26:36 GMT

My opinion is that in production in a web container the StatusLogger should ALWAYS be routed
to stdout. The volume of output should normally be small if you are logging at Error.  Second,
in the ideal case you should only have a single log level, regardless of how many web applications
there are.  To me, anything else is just confusing.  What you are really trying to do with
the StatusLogger is be informed about any errors that may happen in the logging system.  If
you are only logging to a console and everything is uniformly set to Error then I don’t
ever see a problem arising.  

The trouble comes into play when you try to use StatusLogger for something it really wasn’t
intended for. For example, I would only recommend StatusLogger be routed to a file if Debug
is enabled and that should only ever happen outside of a production environment.

I guess what I am saying is that I don’t think we should go overboard trying to make StatusLogger
into something more than what it is - a way to debug errors in the logging configuration or
issues with Appenders.

I am fine with adding javadoc and/or annotations to StatusLogger and its friends to clearly
mark them as for internal use, but I don’t think they are critical enough to hold up on
releasing 2.0.


On Jul 13, 2014, at 11:44 AM, Bruce Brouwer <bruce.brouwer@gmail.com> wrote:

> Rats! It's not so simple as what I wrote.
> The crux of the problem is that the various Configuration classes need to control what
shows up on the console from the StatusLogger. The way they've been doing that is finding
the existing listener and reconfiguring it. There are some problems that will arise as you
add new Configuration instances (e.g. multiple web apps sharing the same classloader) where
these configurations build up over time. Additionally, nothing ever cleans them up as a configuration
is reloaded so you might start logging at debug level to the console even though there is
no configuration telling it to log at debug level. Also, depending on the order of reconfigurations,
you might only be logging fatals to the console even though the current configuration is set
to debug level. 
> It seemed more appropriate to me to introduce a new concept, the StatusFilter. Since
these are really trying to filter what shows up on the console, it seemed more appropriate
than a listener. My solution to these problems is what brought about my API changes to StatusLogger,
which is somewhat significant. But to solve these problems, I think my changes are necessary.
> If we consider these changes important enough, I'd like to get them in before 2.0, even
though some may consider StatusLogger to not be "part of the API" even though it is in log4j-api.

> I checked in the first set of changes to the LOG4J2-609 branch. 
> If we don't make these changes for 2.0, I really want to put JavaDoc on the stuff in
...log4j.status that clearly states this is for internal use only and may change in a breaking
way in the future.
> On Sun, Jul 13, 2014 at 8:41 AM, Remko Popma <remko.popma@gmail.com> wrote:
> On Sunday, July 13, 2014, Bruce Brouwer <bruce.brouwer@gmail.com> wrote:
> Here is what I am thinking. I will make the branch tomorrow and put just the minimal
changes in place with the modified StatusLogger api. This way when I fix things completely
we won't have a breaking api change after 2.0 release. If you like it, we can put just that
in trunk and release.
> Sounds good. 
> On Jul 12, 2014 4:03 PM, "Bruno Mahé" <bmahe@tango.me> wrote:
> Hi,
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have been very
> We are in the process of migrating our services to Apache Log 2.0rc2 so they can be ready
for roll out when 2.0 comes out.
> The only issue we had so far was about configuring async logger for all loggers. Having
to pass system properties to Apache Tomcat in order to activate and configure async loggers
is not convenient.
> There is also a more detailed email/blog post with some numbers we collected being worked
> Thanks,
> Bruno
> On 07/11/2014 05:50 AM, Matt Sicker wrote:
>> Do it! Can't wait! Then I'll be able to upgrade from 1.2 at work. :)
>> On 11 July 2014 03:58, Remko Popma <remko.popma@gmail.com> wrote:
>> No objection at all!
>> I would like to add the tool to generate Custom/Extended Loggers, and do a doc fix
for LOG4J2-631.
>> Also, the site now has an empty section "Custom Plugins" under manual > Extending
Log4j. Shall we remove that before the release?
>> Sent from my iPhone
>> > On 2014/07/11, at 15:50, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>> >
>> > I would like to do the release for Log4j 2.0 this weekend. Are there any objections?
>> >
>> > Ralph
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> -- 
>> Matt Sicker <boards@gmail.com>
> -- 
> Bruce Brouwer
> about.me/bruce.brouwer

View raw message