logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Brouwer <bruce.brou...@gmail.com>
Subject Re: Next release
Date Mon, 14 Jul 2014 21:42:20 GMT
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.goers@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 <garydgregory@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 <garydgregory@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 <garydgregory@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.brouwer@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 <boards@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.brouwer@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 <boards@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>
>>
>>
>
>

Mime
View raw message