logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: 1.2.15 proposed bugs to address
Date Sun, 22 Apr 2007 13:33:44 GMT

On Apr 22, 2007, at 2:09 AM, Paul Smith wrote:

> On 22/04/2007, at 5:00 PM, Curt Arnold wrote:
>> On Apr 21, 2007, at 10:40 PM, Paul Smith wrote:
>>> While sitting in a day spa cafe while my wife got some much  
>>> needed pampering, I sat down and reviewed all the open issues in  
>>> bugzilla and put some thought towards each of them, and where  
>>> they might sit.
>>> What follows is my analysis of what might be worth considering  
>>> tackling in a 1.2.15 release on top of what is already there (I  
>>> actually need to review the diffs between .14 and current status  
>>> too), or as a 1.2.16 release. Be good if we could review and  
>>> agree/change this list and then work towards a release.
>>> These are bugs, not enhancements.  I'll put a separate email  
>>> together with some thought on some 1.2 work we might want to  
>>> consider post 1.2.15 that should be achievable and add value to  
>>> the community.
>>> 1.2.1[56] Potential bug fixes
>>> ==========================
>>> Bug 30588 - log4j cannot parse stacktraces from JRockit
>>> 	simple fix
>> Looked at this one last night.  The change seems innocuous but  
>> that is supposing there isn't yet another VM that works with the  
>> current implementation and fails with the suggested.  At least  
>> before committing this, I think that we'd have to check the unit  
>> tests pass on JRockit with the fix.  Better yet, check it on some  
>> set of implementations.  Anybody want to throw out a list of VM's  
>> that should be checked (better all run on Intel on either Mac OS,  
>> Linux or Windows for me to help).
> We could defend against that by only using a different algorithm  
> when the underlying JVM version is JRockit, and use the standard  
> algorithm for other VM's, or do you think that's getting hacky?  A  
> system property read on class init to detect jrockit-ness?

Probably just a quick survey of stack trace formats from other JVMs  
would be in order.  The change is likely safe, just need to be sure.

I know that the unit tests fail with gcj java due to a slightly  
different layout (maybe just a whitespace difference) on stack traces  
that are written to the generated log files.  Getting the unit tests  
to run on various VMs might be a bit of work.

>>> Bug 37736 - LoggerEventListener's appenderRemovedEvent() and  
>>> levelChangedEvent() methods are never called
>>> 	this is, according to the bug report, both 1.2 and 1.3 related  
>>> (see below).  Worth investigating.
>> I'm thinking that it is 1.3 specific as LoggingEventListener  
>> doesn't exist in log4j 1.2.
> Fair point, if that listener interface isn't in 1.2, we could just  
> consider it for 1.3 changes.
>>> Bug 17531 - PropertyConfigurator.configureAndWatch() don't reset  
>>> the configuration
>>> 	some work done in trunk, is it worth reviewing for a port?
>> I'd be concerned that this is a change of behavior that would  
>> break someone who depended on the old interpretation.  I think  
>> that log4j 1.3 added an explicit reset property so that you could  
>> explicitly request a reset before reconfiguring.
> Yes, could go either way, we could defer this one for later 1.2.x,  
> if at all.

My gut is defer that one.

> On the whole though, happy with that set as a target for the next  
> release?  I'd like to finalise a maven pom.xml for the 1.2 branch  
> as well.  We shouldn't need to move the repo around, I think  
> there's a pom setting element to define the source folders.
> I'm also getting my gpg setup as well, so we can have a few more  
> people capable of signing the releases.  Only yourself and Mark  
> have your stuff in the KEYS file.  Once I get my head around it, do  
> I simply append my signature to that file?  I'm gathering I won't  
> get my signature signed into the Web of Trust for a while, given  
> I'm Down Under.

That sounds right.

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message