logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Brouwer <bruce.brou...@gmail.com>
Subject Re: Next release
Date Sun, 13 Jul 2014 23:50:39 GMT
Should double check better. Should not be a real performance issue
On Jul 13, 2014 7:35 PM, "Remko Popma" <remko.popma@gmail.com> wrote:

> I haven't studied StatusLogger in that much depth, but what you're saying
> sounds good. I agree with Ralph that this is for diagnostics and it's
> better to keep this simple.
>
> Sent from my iPhone
>
> On 2014/07/14, at 8:19, Bruce Brouwer <bruce.brouwer@gmail.com> wrote:
>
> I'm all for making this more like a simple on/off switch. But the way
> things are setup right now, once you turn on the console logging, it can
> never be turned off. That is because once it is registered, nothing ever
> removes it.
>
> Are we ok with that?
>
> If we are, then I would like to remove all the level checking that is done
> in StatusLogger regarding these listeners and always have logs sent to the
> listeners. Let the listeners decide if they want to log something. Like was
> said, there are so few events it should be a performance issue.
>
>
> On Sun, Jul 13, 2014 at 4:39 PM, Matt Sicker <boards@gmail.com> wrote:
>
>> I agree with Ralph on all counts regarding StatusLogger. Really, anything
>> that wants to store the StatusLogger output elsewhere is probably using
>> standard out redirection.
>>
>>
>> On 13 July 2014 15:34, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>>
>>> Also, I am against renaming StatusLogger as it will result in
>>> modifications to hundreds of files.
>>>
>>> Ralph
>>>
>>> On Jul 13, 2014, at 1:08 PM, Ralph Goers <ralph.goers@dslextreme.com>
>>> wrote:
>>>
>>> Gary, the 2.0 release vote is already in progress.  I don’t see adding
>>> an annotation or comment marking something as for internal use as a reason
>>> to hold up the release.
>>>
>>> No to renaming StatusLogger. It’s name is perfectly clear to me.
>>>
>>> Ralph
>>>
>>> On Jul 13, 2014, at 1:04 PM, Gary Gregory <garydgregory@gmail.com>
>>> wrote:
>>>
>>> I am hoping this will get cleaned up for the 2.0 release, especially if
>>> this affects the log4j-api module. As soon as we publish 2.0, folks will
>>> have a green light to implement their own loggers and solution and get
>>> hard-wired to the API. As a user, I would imagine that anything in
>>> log4j-api would be set in stone...
>>>
>>> While we are here: I always found the class name StatusLogger confusing
>>> (as is the package), for me InternalLogger (or PrivateLogger), would be
>>> clearer.
>>>
>>> Gary
>>>
>>>
>>> On Sun, Jul 13, 2014 at 3:12 PM, Matt Sicker <boards@gmail.com> wrote:
>>>
>>>> I suggest making an annotation or something to use for all the
>>>> internal-use classes that are in log4j-api. It also helps to make internal
>>>> use APIs all in separate packages from public APIs. That way you can make
>>>> it extra obvious that if the internal API changes, too bad.
>>>>
>>>>
>>>> On 13 July 2014 13:44, 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 impressed.
>>>>>>>> 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 on.
>>>>>>>>
>>>>>>>> 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
>>>>> [image: Bruce Brouwer on about.me]
>>>>>    <http://about.me/bruce.brouwer>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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>
>>
>
>
>
> --
>
>
> Bruce Brouwer
> about.me/bruce.brouwer
> [image: Bruce Brouwer on about.me]
>    <http://about.me/bruce.brouwer>
>
>

Mime
View raw message