You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Smith <ps...@aconex.com> on 2007/04/22 05:40:42 UTC
1.2.15 proposed bugs to address
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
Bug 40888 - Weekly rotation problem in Europe
test case provide, good chance of success
Bug 21796 - SocketAppender doesn't fall back with FallbackErrorHandler
Test case is there, not attached however, and is probably why no-one
has bothered to try and integrate the change. This one looks important.
(Sort of 1.2 related) Bug 34440 - sandbox:IMAppender - comma-
seperated recipient list patch
- just need someone to interpret the patch pasted into the
comment. Effort is small though.
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.
Bug 38061 - Problem configuring an errorHandler using a property file
bug report is a little hard to understand whether the proposed fix
works all the time. Possible chance of a test case to be written?
Bug 40159 - NullPointerException in org.apache.log4j.NDC.get
both NDC and MDC need to be looked at here.
Bug 40349 - RollingFileAppenders do not getFooter() from Layout
Bug 40350 - DailyRollingFileAppender should not write Layout header
on resume
Bug 40951 - log4j 1.2.15 release
Very easy to do, once we have a 1.2.15 release!
Bug 40990 - Cannot bind port or ip address for outgoing UDP socket
when using SysLogAppender
Seems sensible to do
Bug 41316 - NPE when using RollingFileAppender in Tomcat.
Could be closed off it it really is a Tomcat problem?
Bug 42017 - InstanceAlreadyExistsException using MBean
this one might be a duplicate of another open bug I saw in the list,
but worth considering
Bug 16280 - Error Message always logged to log4j when calling close()
on TelnetAppender
Issue already addressed in trunk, just needs review and port to 1.2
Bug 17531 - PropertyConfigurator.configureAndWatch() don't reset the
configuration
some work done in trunk, is it worth reviewing for a port?
Bug 25107 - OptionConverter.getSystemProperty() does not allow
substitution
I think this has a duplicate in there as well. Bug 14350 ?
Bug 29227 - Reduce first connection failure severity in SocketAppender
I tend to agree with the reporter, although there are cases when
this is bad and needs to be noticed. If it's _that_ important, then
they should set a FallbackErrorhandler?
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.2.15 proposed bugs to address
Posted by Curt Arnold <ca...@apache.org>.
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
Re: 1.2.15 proposed bugs to address
Posted by Paul Smith <ps...@aconex.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: 1.2.15 proposed bugs to address
Posted by Curt Arnold <ca...@apache.org>.
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).
>
> Bug 40888 - Weekly rotation problem in Europe
> test case provide, good chance of success
>
> Bug 21796 - SocketAppender doesn't fall back with FallbackErrorHandler
> Test case is there, not attached however, and is probably why no-
> one has bothered to try and integrate the change. This one looks
> important.
>
> (Sort of 1.2 related) Bug 34440 - sandbox:IMAppender - comma-
> seperated recipient list patch
> - just need someone to interpret the patch pasted into the
> comment. Effort is small though.
>
> 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.
>
> Bug 38061 - Problem configuring an errorHandler using a property file
> bug report is a little hard to understand whether the proposed fix
> works all the time. Possible chance of a test case to be written?
>
> Bug 40159 - NullPointerException in org.apache.log4j.NDC.get
> both NDC and MDC need to be looked at here.
>
> Bug 40349 - RollingFileAppenders do not getFooter() from Layout
>
> Bug 40350 - DailyRollingFileAppender should not write Layout header
> on resume
>
> Bug 40951 - log4j 1.2.15 release
> Very easy to do, once we have a 1.2.15 release!
>
> Bug 40990 - Cannot bind port or ip address for outgoing UDP socket
> when using SysLogAppender
> Seems sensible to do
>
> Bug 41316 - NPE when using RollingFileAppender in Tomcat.
> Could be closed off it it really is a Tomcat problem?
>
> Bug 42017 - InstanceAlreadyExistsException using MBean
> this one might be a duplicate of another open bug I saw in the
> list, but worth considering
>
> Bug 16280 - Error Message always logged to log4j when calling close
> () on TelnetAppender
> Issue already addressed in trunk, just needs review and port to 1.2
>
> 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.
>
> Bug 25107 - OptionConverter.getSystemProperty() does not allow
> substitution
> I think this has a duplicate in there as well. Bug 14350 ?
>
> Bug 29227 - Reduce first connection failure severity in SocketAppender
> I tend to agree with the reporter, although there are cases when
> this is bad and needs to be noticed. If it's _that_ important,
> then they should set a FallbackErrorhandler?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org