Ceki Gülcü <[EMAIL PROTECTED]> wrote on 12/27/2004 05:31:23 PM:
>
> At 2004-12-16 16:51:31, Richard Sitze wrote:
>
> > I do not advocate a fail-on-no-config or fail-on-ambiguous-config.
> >
> > I advocate a *warn* or *error* on either, using the simple default
logger.
> > The warning will be visible on the console, which suffices for my
> > immediate concerns. How that warning/error (in general) is managed
is up
> > to the application environment.
>
> Log4j 1.3 can use itself for its own logging. So, when appender A
> fails, it can report errors using appender B. Appender B could alert the
> system admin if that is the desired behavior.
>
> The same goes for configuration errors which are also accessible
> programmatically. For example,
>
>
> Configurator c = new SomeLog4jConfigurator();
> c.configure("some file");
> List el = c.getErrorList();
> if(el.size > 0) {
> if(analyzeErrors(el)) {
> // errors during logging configuration
> throw new IllegalStateException("Can't proceed withour logging");
> }
> }
>
> boolean analyzeErrors(List el) {
> // custom analysis of the errors go here
> return true/false;
> }
>
> It seems to me that log4j already fulfills Richard's requirements wrt
> logging errors and logging configuration.
It lends it's self well to this, but it's not sufficient. The requirement
is for this behavior to be exhibited by JCL, for example when Log4j is
configuted, but not available on the classpath.
>
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
