DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34661>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34661 ------- Additional Comments From [EMAIL PROTECTED] 2005-06-12 05:21 ------- (In reply to comment #32) > 1) Invocation of constructor in createLogFromClass I think this should be fixed in LogKitLogger rather than in LogFactoryImpl. The issue is telling the difference between a logging implementation *not being available* and the logging implementation being available but broken. When the logging impl is not available, discovery should continue. But I think that when it is available but broken we should throw an exception rather than mysteriously redirecting output to another logging implementation. It's difficult to tell these apart, but I would suggest specifying (in the Log interface javadoc) that a NoClassDefFound or an ExceptionInInitializerError should indicate "not available" while an InvocationTargetException indicates available-but-broken. This is the approach that I took with Jdk14Logger, where there is a dummy variable that forces an ExceptionInInitializerError if java.util.logging.Level is not available. I expect a similar thing could be done with LogKitLogger... Thoughts? > > 2) Main try/catch block in createLogFromClass specifically catches and > rethrows > LCE. Otherwise LCE thrown by handleFlawedHierarchy will needlessly be wrapped > by another LCE in the final "catch Throwable" block. Well spotted. I'll commit this ASAP -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
