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 >
