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
