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>
