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
