DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

DO NOT REPLY [Bug 34661] - [logging][PATCH] Improvements to LogFactoryImpl

Bugzilla from bugzilla@apache.org
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 [hidden email]  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: [hidden email]
For additional commands, e-mail: [hidden email]