logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Next release
Date Sun, 13 Jul 2014 23:44:12 GMT
If it can't be turned off that doesn't sound right.  You should be able to get to the listener
and change its level so that nothing is logged.  I guess you are meaning the listener can't
be removed?  For some reason I thought it could.

Ralph

> On Jul 13, 2014, at 4:19 PM, 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
>>>>>>> 
>>>>>>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Matt Sicker <boards@gmail.com>
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com 
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> Matt Sicker <boards@gmail.com>
> 
> 
> 
> -- 
> 
>  
> Bruce Brouwer
> about.me/bruce.brouwer
> 
>  

Mime
View raw message