On Sun, 2005-05-22 at 15:59 -0700, Brian Stansberry wrote: > > > >i believe (as indicated in the analysis document) > that the correct > >behaviour in these cases is for JCL to recognise that > log4j is not > >viable (for this configuration) and default to > java.util logging. this > >is a little unsatisfactory but i don't see a > reasonable technical > >solution for these configuration. > > > > One unsatisfactory aspect is that instead of throwing > an exception with a nice message and stack trace, > logging would mysteriously be done using an unexpected > logging library. But Simon's recent work on adding > diagnostics should help mitigate this drawback.
I presume you're continuing the discussion: http://issues.apache.org/bugzilla/show_bug.cgi?id=34661 The bit about trying to instantiate a logger object in order to test whether that library is *really* available has my +1. The bit about ignoring the situation where we can't cast the resulting object to Log (and continuing with discovery) is something I've been trying to make up my mind on. When the user *has* put an implementation of the Log interface into the child classloader, so that this problem occurs, we can: a) report an error, or b) use a logging lib that the parent can access When the user doesn't actually have any interest in log output, (b) is obviously superior. It's a shame that at the moment we prevent apps from running even when no logging would ever be generated. Falling back to another implementation (even SimpleLog or NoOpLog) is fine when no output is generated or the user doesn't want the output! And sometimes the user is happy with (b) anyway, ie they feel it's ok that logging from code in the child goes to one destination while logging from code in the parent (even when directly invoked by the child) goes elsewhere. But sometimes users will *really* expect all their logging to go to one place regardless of whether the code is deployed in the child or parent. And in this situation, silently "splitting" the output will really confuse them. In the past, I've had a slight lean towards (a), ie the current solution. If the system *might* do unexpected things it seems safer to report the error than not. But now diagnostics are available, I could be persuaded towards implementing the proposed patch. The situation where the app terminates in the middle because child code called parent code that uses logging is nasty. And with diagnostics, a user who wonders "why didn't my logging output go where I expected it?" can find out. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
