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.brou...@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 <boa...@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.go...@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.go...@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 <garydgreg...@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 <boa...@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.brou...@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.po...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Sunday, July 13, 2014, Bruce Brouwer <bruce.brou...@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é" <bm...@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.po...@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.go...@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-unsubscr...@logging.apache.org >>>>>>>>>>>> > For additional commands, e-mail: >>>>>>>>>>>> > log4j-dev-h...@logging.apache.org >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>>>>>>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> Bruce Brouwer >>>>>>> about.me/bruce.brouwer >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>> >>>>> >>>>> >>>>> -- >>>>> E-Mail: garydgreg...@gmail.com | ggreg...@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 <boa...@gmail.com> > > > > -- > > > Bruce Brouwer > about.me/bruce.brouwer > >
