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...
[1] http://www.qos.ch/logging/classloader.jsp
- robert
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
