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

<div>-------- Original message --------</div><div>From: Bruce Brouwer 
<bruce.brou...@gmail.com> </div><div>Date:07/13/2014  22:35  (GMT-05:00) 
</div><div>To: Log4J Developers List <log4j-dev@logging.apache.org> 
</div><div>Subject: Re: Next release </div><div>
</div>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

 



-- 

 
Bruce Brouwer
about.me/bruce.brouwer

 

Reply via email to