Should double check better. Should not be a real performance issue On Jul 13, 2014 7:35 PM, "Remko Popma" <remko.po...@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.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 >>>>> [image: Bruce Brouwer on about.me] >>>>> <http://about.me/bruce.brouwer> >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@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 <boa...@gmail.com> >> > > > > -- > > > Bruce Brouwer > about.me/bruce.brouwer > [image: Bruce Brouwer on about.me] > <http://about.me/bruce.brouwer> > >
