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