--- Richard Sitze <[EMAIL PROTECTED]> wrote: > 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? > > The current proposal is: > > - configuration is always manditory.
Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. David > > - ambiguous [multiple] configurations located by a particular > ClassLoader > in the hierarchy requires an "error" to be logged [where is a reasonable > > question to ask]. How we determine which configs belong to which > ClassLoaders is described in the original proposal. > > - in a "core" JCL jar, a configuration *must not* be packaged with JCL. > > - in a "helper" JCL jar, a configuration *must* be packaged, along with > *one* JCL logger wrapper class. > > - multiple "helper" JCL jar files, one per logging impl wrapper we > support. Pick the logger impl you want, grab the corresponding "helper" > > JCL jar file, and drop it into your application. > > > > > > Regards, > > > > Simon > > __________________________________________________ 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]
