I think this demonstrates a major issue.
When using logging in an "enterprise" situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur.
But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start.
The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a "fail-on-no-config" option!
So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the "be quiet on no config", while the "enterprise" commons-logging jar would do something like "write message to STDERR then throw a runtime exception on no config"?
Why not just introduce a boolean parameter that says whether or not an inability to log is a failure? e.g.
Log log = LogFactory.getLog(MyClass.class, true);
Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
