On Sun, 2005-04-24 at 23:59 -0700, Brian Stansberry wrote: > --- robert burrell donkin
<snip> > > i suspect that many of failure cases in #3 are > > caused by JCL being able > > to load one or more of the appropriate classes by > > name from a > > classloader but then throw an exception when they > > are not compatible. > > IMHO this behaviour is counter-productive. in this > > case, rather than > > throwing a runtime exception, JCL should conclude > > that log4j is actually > > not really available and use java.util.logging > > instead. > > > > any opinions about changing JCL so that this > > approach is adopted? > > > > +1. If the chosen logger cannot be loaded, the mode of failure i tried to indicate above is a little more subtle: the classloader that defines Log in LogFactoryImpl is not the same as the one that defines Log in the loaded implementation. this results in a lot of confusion for users. in these cases, getLogConstructor() performs a check which has the effect of checking whether the classloaders are compatible. if they are not compatible, then it throws a runtime exception. maybe it would be more reasonable in this case to simple try to load the same class from the class classloader and see if that's compatible. opinions? (i suspect that the reason this approach was taken was security. not sure whether there's any practical security advantage in killing an application rather than loading using the class classloader. may to think further on this one, though.) > a message > to System.out and/or System.err should be recorded, > and then fall back to JDK logging, and then to > SimpleLog. I don't think logging frameworks should > throw runtime exceptions. i agree (but that's the strategy adopted by JCL). IIRC the original arguments were security and lack of effective diagnostics. i think that a diagnostics system property would be a good idea. if this property is set, JCL would write out useful diagnostic information (especially about discovery) to System.err. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
