Just for the record, the primary issue is NOT inability to locate a logger. It's not finding the "expected" logger [from the developer/users perspective], and silently falling back to an "alternate" logger.
******************************************* Richard A. Sitze IBM WebSphere WebServices Development Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 10:18:44 PM: > On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote: > > Simon Kitching wrote: > > > 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); > > It's not "inability to log" as such. It's whether finding no specific > config info or underlying log implementation and therefore falling back > to using java.util.logging (java>=1.4) or > org.apache.commons.logging.SimpleLog (java<1.4) is allowed or not. > > In many cases, what you *want* an app to do if it can't find any > specific logging config is simply to output ERROR and FATAL messages to > stderr. This is what commons-logging will currently do if its > "discovery" process finds nothing. > > I guess commons-logging *could* use a parameter such as you suggest to > indicate "explicit configuration of logging is mandatory". This would > presumably mean detecting whether commons-logging.properties or the > corresponding system properties have defined an explicit log > implementation and config file for that implementation. > > I'm not sure, however, if the decision on whether logging is mandatory > or not should be a compile-time one. It seems to me to be more like > something the application *deployer* should choose. That then leads us > to a circular reference: how do we know whether configuration is > mandatory or not, if we can't find any configuration? > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
