On Wed, 27 Mar 2002, Ceki Gülcü wrote: > At 10:15 27.03.2002 -0800, [EMAIL PROTECTED] wrote: > >The goal is not to be able to change the logger at compile time, but to be > >able to detect the platform logger and use it. The only way to do that is > >via a standard API - and commons-logging seems to be the only standard for > >logging that we have, supported ( mostly unwillingly :-) on all logging > >implementations. If you are concerned about the user experience with > >commons-logging and log4j, the best way to resolve that is by > >participating in commons-logging and implementing it in log4j so that > >log4j will work best with commons-logging. > > Rodney argued that the goal was to make commons components > non-intrusive with respect to logging.
Well, there are more than 2 goals :-) > If the goal is to detect (or guess) at run time the logging API to > use, then this will only increase uncertainty and confusion. I know of > a few frameworks (no, I won't tell you the names) that do this and it > does not provide for a pleasant experience. Even I had trouble to set > up logging and just gave up. No, 'detecting/guessing' is not a goal - it's just one possible implementation - for the goal of allowing multiple implementations. The goal here is to support multiple logging _implemementations_, and provide a common/standard API for components to use. By 'standard API' I mean the same thing as SAX - if you use SAX your code will work with any parser that implements the SAX API. It's certain that each parser ( and logger ) may have some better internal APIs. > To be brutally honest, I think the commons-logging approach is counter > productive. It may seem like the politically correct thing to do but > it will increase complexity and prove to be unproductive in the long > run. I thank you for the invitation to participate in the I don't know any alternative to commons-logging. If you know any, I would be happy to learn about it. Without an alternative, the only possible approach is to improve commons-logging. Using log4j API and doing 'string replace' if you want to use another logger is absurd, I hope you weren't serious about proposing that. Unfortunately JDK1.4 logging API is not useable as a 'standard' for logging, and no other accepted standard exist (AFAIK). We have multiple logging implementations, and the only solution I know is to use an API that works will all of them. I don't know what's 'conter productive' about it, it worked fine for SAX. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
