Hi Ceki,
On Fri, 03 Dec 2004 13:49:39 +0100 Ceki G�lc� <[EMAIL PROTECTED]> wrote:
Hello Andy,
Thank you for taking the time to express your concerns. I appreciate
it. While I agree with most of your comments, it think it is important
to put them in relation with the facts.
1) The NPE problem cannot be triggered from configuration files but
only by java code actively trying to set up a custom
RepositorySelector. At this time, very few people do that.
I agree, the problem is likely to be rare but I was concerned that because the impact
can be so severe to the appserver, that a few occurrences could spread FUD about the stability of the 1.3 release.
2) Item 1.2 in the FAQ, is one of the guiding principles behind
log4j. You correctly point out that not catching the NPE contravenes
this principle.
My argument is two fold.
1) This particular NPE problem concerns only few select developers all
of which are expected to be of high caliber or at least curious enough
to spend a few cycles on the problem. (Admittedly, they can make
mistakes too.)
Agreed. Any developer working with the 1.3 alpha release should be prepared to 'spend a few cycles'
on any 'issues'. I'm having several interesting problems trying to build and run the log4j unit tests at the moment
on my system which I suspect are due to my environment not being quite right yet after a recent clean OS re-install :-(
I was just hoping that this type of issue could be resolved by the time 1.3 reaches release candidate?
2) The particular defensive solution proposed was of the
"ignore the developer, log4j knows best" kind. Hence, my -1.
I understand your caution. Whilst an end-user application can freely validate and prevent illegal
input, a library such as log4j should not generally 'second-guess' the developer.
My understanding is that this problem will only occur if the developer fails to correctly configure the repository selector. The only issue is how log4j handles this recognised problem. It can either: 1) throw a NPE, IllegalStateException or other unchecked runtime exception potentially halting the VM. 2) throw a new specific checked exception (SelectorConfigException) forcing the developer to explicitly catch and deal with the scenario as he feels fit). 3)ignore the developer and use a default which may not be what the developer expects.
Catching the NPE and providing the user with a useful pointer (pun
unintended) is a solution worth exploring. However, currently we have
other problems affecting many more users, hence my request to put the
NPE aside for the time being. We can easily come back to it later.
Ok. The current frenzy around the 1.3 alpha release is great to see. I would love
to help increase the quality of the release in any way I can. I was hoping to find some time to start increasing the unit test coverage and javadoc along with testing the new functionality.
Apart from the new stuff in HISTORY.txt can you suggest any other areas in need of attention or more
unit testing?
The clover unit test coverage analysis suggested by Curt Arnold in the "Joran, RollingFileAppender, and Rollover failure warnings" thread would be useful here. I have also found this tool useful in the past, simply to highlight areas of the code possibly in need of
love and attention.
Perhaps I should also create a bugzilla item to track this NullPointer issue and link it to this thread so it
can be re-visited later with fresh-eyes when the current sprint is done?
Regards
Andy
At 02:00 AM 12/3/2004, Andy McBride wrote:Please don't allow log4j to throw any unnecessary RuntimeException's be they NullPointers or IllegalStateExceptions.
According to the log4j FAQ question 1.2:
"log4j will not throw unexpected exceptions at run-time potentially causing your application to crash. If for any reason, log4j throws an uncaught exception, please send an email to the [EMAIL PROTECTED] mailing list. Uncaught exceptions are handled as serious bugs requiring immediate attention"
Simply documenting the problem will not help.
"... the RepositorySelector API is designed to be used by developers of Application Servers or 1st class passengers on the clue train..." - I would hope that there are more than 5 of these currently on planet earth and that some of them are capable of mistakes too! Far too many people only get round to reading the docs after the problem has occurred.
If I supply log4j with an invalid config file I do not expect it to crash the appserver, similarly if I programatically configure log4j RS incorrectly I also do not expect it to crash the appserver.
Putting my Miss Piggy hat on, I think I would always prefer log4j to ignore me and carry on with its existing basic default behaviour if I tried to instruct it to do something silly. A specific checked exception could be (self-f)logged pointing to the exact problem with the config.
These are just my humble opinions, please let the debate on this run a bit longer.
Regards
Andy
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The information contained in this e-mail is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If You are not the intended recipient of this e-mail, the use of this information or any disclosure, copying or distribution is Prohibited and may be unlawful. If you received this in error, please contact the sender and delete the material from any computer. The views expressed in this e-mail may not necessarily be the views of The PCMS Group plc and should not be taken as authority to carry out any instruction contained.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
