------- 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
> 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.