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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
