commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [logging] discovery error handling
Date Fri, 11 Feb 2005 21:49:24 GMT
At 11:25 PM 2/8/2005, you wrote:
>one of the drawbacks about JCL 1.0.x is the approach to handling errors
>in the configuration and discovery mechanism. JCL falls down and (in
>most commons use cases) takes the application with it. it also fails to
>provide useful diagnostic information.
>i've been considering for a while adopting a system for error handling
>which allows a system property to be used to tune the exactly behaviour:
>classic more would throw runtimes (as per now), silent more would
>suppress all issues continuing to function as well as it is able and
>diagnostic would print diagnostic information to System.out. though not
>all environments would allow system properties to be set, i think that
>this would improve matters for many common use cases.

Considering that logging often doubles as an error reporting system,
it must be very robust to begin with. One of the toughest problems
addressed in log4j version 1.3 the way log4j logs internally generated
messages using itself recursively. In certain special cases, log4j
needed a fallback logging API for its own use and that is how UGLI
came into being.

Coming back to JCL, printing something on the console in case of
errors is not enough. JCL must to also return a valid Logger back to
the application. Anyway, before camouflaging errors occurring during
Logger retrieval, I'd recommend that you fix the bug exposed by
Example 2 in my analysis [1]. In my opinion it cannot be fixed without
a major redesign and overhaul of JCL, but maybe I am wrong...


>- robert

Ceki Gülcü

   The complete log4j manual:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message