--- Simon Kitching <[EMAIL PROTECTED]> wrote: > On Tue, 2005-06-14 at 23:31 -0700, Brian Stansberry > wrote: > > > Re the InvocationTargetException for > LogKitLogger: > > > > > > Does it actually matter whether > > > ExceptionInInitializerError or > > > InvocationTargetException occurs for > LogKitLogger? > [snip] > > Depends on how we resolve the issue of whether to > ever > > fall into discovery if a relevant ALLOW...PROPERTY > was > > set. In the case of InvocationTargetException, > > ALLOW_FLAWED_DISCOVERY_PROPERTY would come into > play. > > True. > > As I said in the bugzilla note, I'm tempted to leave > things as they are > (no attempt to recover from problems when user > specifies a particular > library themselves). But I'm open to persuasion... >
Not going to try to persuade, as I've come around to your point of view. My nagging concerns were 1) avalon/logkit users would not be able to get JCL to run in certain situations and 2) the different behavior when using commons-logging.properties would be confusing to document and explain. Had a chance to look carefully at all the places where behavior with c-l.properties differs from normal discovery. As you've noted, many could be resolved with standard advice like "use the commons-logging-adapters.jar" or "put a copy of logkit.jar in the parent loader classpath". The rest were odd cases involving a broken TCCL where some kind of special instructions would have to be given in any case. A big upside of the "no attempt to recover" approach is even log4j users can use c-l.properties and thus force LCE's in situations where JCL would otherwise fall back to JDK logging. For example, to avoid a situation where someone forgets to deploy log4j.jar in the parent classpath, so the special "wake up the SA at 4:00AM whenever there is an error" appender never gets called. > > Even if we decide _not_ to ever fall into > discovery, > > its mildly tempting to patch LogKitLogger so it > fails > > with the ExceptionInInitializerError. Just so if > some > > poor guys three years from now change something, > the > > bug won't suddenly pop out. > > That's fine by me. If you provide a patch I'll > happily commit it. > Will do. Best, Brian __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
