I am thinking I will commit my changes for 609 to the trunk tonight (unless i hear otherwise) to get it included in 2.0. The impact to -api is pretty small so I will leave it to you to decide if we need an rc3. My vote is we do. With this change I consider 609 to be resolved. On Jul 14, 2014 5:42 PM, "Bruce Brouwer" <bruce.brou...@gmail.com> wrote:
> In the latest stuff in my branch, the biggest change in api is > StatusConsoleListener moved to -core > On Jul 14, 2014 1:23 PM, "Ralph Goers" <ralph.go...@dslextreme.com> wrote: > >> StatusLogger is public in the sense that user written components will use >> it. But all we really expose to components there is the >> StatusLogger.getLogger() and the Logger interface. The other public methods >> there are for JMX and the configuration to access the status data. Nothing >> else under the status package is really public. >> >> I haven’t looked at Bruce’s changes yet but I can’t imagine how they >> would result in API breakage. >> >> Ralph >> >> >> >> On Jul 14, 2014, at 10:04 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >> If we break binary compatibility then we should change the package name. >> This is to avoid well know jar hell issues. What we need to decide is which >> APIs are really public. For example in Commons, all public APIs are part of >> the binary compatibility agreement we've made. We now have lang3, pool2, >> dbcp2, for example. Looking ahead to not breaking binary compatibility is >> why I think we need to be sure we agree now on what the public API is. >> >> Gary >> >> >> -------- Original message -------- >> From: Remko Popma >> Date:07/14/2014 12:43 (GMT-05:00) >> To: Log4J Developers List >> Subject: Re: Next release >> >> Bruce, I've done an initial review of the LOG4J2-609 branch and posted >> some comments in the Jira. >> >> Gary, I'm not in principle against changes to the API module in post-2.0 >> releases. Changes need to have enough merit to justify them, but if they >> do, then making these changes before or after 2.0 doesn't matter that much >> to me. We've been in beta so long that I'm sure we have quite a few users >> already, so to me we are live already. >> >> I do appreciate you want it to be as close to perfect as we can make it. >> But I also agree with the others that releasing a GA version now won't >> prevent us from making further improvements. >> >> By the way, when I told some people at work that we're close to the 2.0 >> release, their first impression was: "finally!" :-) >> >> >> On Mon, Jul 14, 2014 at 9:32 PM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >>> I'll give the VOTE a review of course but I do not see the harm in >>> another RC since we will be setting the API in stone as soon as 2.0 is out. >>> We also have only one shot at a first impression. >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Ralph Goers >>> Date:07/14/2014 00:35 (GMT-05:00) >>> To: Log4J Developers List >>> Cc: Logging PMC >>> Subject: Re: Next release >>> >>> I guess that means you won't be voting on the current release candidate? >>> Pretty much everyone else thinks it is time. If that is the case one of the >>> other PMC members will need to fail or the release vote will fail. >>> >>> For what it is worth, I have no problem with a 2.0.1 or 2.1 in a few >>> weeks if desired. I just think we have been stalling long enough. >>> >>> And I hope we continue to keep fixing things at the same, or better, >>> pace. >>> >>> Sent from my iPad >>> >>> On Jul 13, 2014, at 8:28 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>> I'd be ok with another RC. My ideal scenario is that an RC is released, >>> some time goes by without new bug reports and then the next RC becomes a >>> release. As things are now, we've fixed plenty since rc2. But hey that's >>> just me ;-) >>> >>> Gary >>> >>> >>> -------- Original message -------- >>> From: Bruce Brouwer >>> Date:07/13/2014 22:35 (GMT-05:00) >>> To: Log4J Developers List >>> Subject: Re: Next release >>> >>> Ok, the only test that didn't pass was the one testing for StatusLogger >>> writing to a file. I removed that test on the branch. If you review that >>> and think it worthy to go into the trunk, I'm pretty much on board with a >>> 2.0 release (unless you think a short lived rc3 is in order). >>> >>> >>> On Sun, Jul 13, 2014 at 9:29 PM, Bruce Brouwer <bruce.brou...@gmail.com> >>> wrote: >>> >>>> Ok, this is starting to be simpler, as I'm sure you would all prefer. >>>> You can look at the branch LOG4J-609 again if you like. Here are the >>>> simplifications that I have made. >>>> >>>> 1) The listeners no longer report their level. They can decide if they >>>> want to do something with a status message in their log method. >>>> 2) There is no longer the option to configure the StatusLogger to write >>>> to a file. >>>> 3) I moved StatusConsoleListener out of log4j-api and into log4j-core, >>>> where we can probably get away with making more drastic changes to it in >>>> the future (so I can fix LOG4J-609) >>>> >>>> I have to check on the tests and stuff, but in general, I'm pretty >>>> happy with how small the impact is and in its ability to make a better >>>> solution for LOG4J-609 possible in the future. >>>> >>>> >>>> On Sun, Jul 13, 2014 at 8:23 PM, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>>> This actually makes me wonder why you can configure the status logger >>>>> from a configuration file. Shouldn't this just be a system property or >>>>> something? >>>>> >>>>> >>>>> On 13 July 2014 18:57, Bruce Brouwer <bruce.brou...@gmail.com> wrote: >>>>> >>>>>> The listener can be removed, but nothing ever does. Right now it can >>>>>> never know if it should be removed. And also, all that level checking is >>>>>> cached in StatusLogger. If all you do is change the status level of the >>>>>> listener it has no effect on the cached value in StatusLogger. It may end >>>>>> up having no effect. >>>>>> >>>>>> This is some of the stuff I was trying to clean up with my fix that I >>>>>> have been delinquent with. >>>>>> >>>>>> I will try to simplify this on the branch and see if it makes sense >>>>>> in the next hour or two. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <boa...@gmail.com> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> Bruce Brouwer >>>> about.me/bruce.brouwer >>>> [image: Bruce Brouwer on about.me] >>>> <http://about.me/bruce.brouwer> >>>> >>> >>> >>> >>> -- >>> >>> >>> Bruce Brouwer >>> about.me/bruce.brouwer >>> [image: Bruce Brouwer on about.me] >>> <http://about.me/bruce.brouwer> >>> >>> >> >>
