On Fri, 2005-02-11 at 21:49, Ceki Gülcü wrote: > 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.
valid loggers are pretty easy to return. the problem is that the type of logger may differ from the one the deployer expects. at the moment, JCL just throws a runtime when things go wrong. this can be very annoying. i suspect that this was done as part of the conservative approach to isolating different application in containers. > 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... this general issued was discussed earlier. i suspect that it would be possible to improve the situation in JCL1 but richard's more sceptical and seems keener to push straight towards JCL2. i think that there's some danger that momentum is starting to slip away so i'm probably not going to look at fix the issue in the 1.0.x stream right now. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
