At 13:24 16.08.2001 -0700, [EMAIL PROTECTED] wrote:
>On Thu, 16 Aug 2001, Morgan Delagrange wrote:
>
>> Although I wish it was not necessary, it seems like if the Logging component
>> gets voted down, we'll end up with no logging at all, not Log4J logging. I
>> think that the Logging component is a reasonable abstraction, and I can't
>> stand by and watch logging itself disappear. So I have to give the Logging
>> component +1.
>
>To reestablish the balance of votes, here's my -1 for the Logging
>component :-)
>
>Using "Logging" APIs instead of Log4J APIs, and requiring the "Logging"
>component instead of Log4J component is _bad_. Log4j may have problems,
>but it's reasonably easy to solve them - a simpler Category, fewer classes
>visible to the user, etc. Instead of inventing another logger, we should
>fix log4j. Or push Ceki to adopt some of the ideas in Logging and make
>them available in log4j.
Hi Costin,
I agree that simplifying the log4j API offers advantages. Nevertheless,
the log4j API can change only if the changes are backwards compatible.
Category class being a class and not an interface has some
disadvantages. At the time, it was a deliberate decision in favor of
performance. If I had to do it again, I'd probably do it
differently.
As I said, I am all in favor of refactoring the log4j API but only if
we can ensure a smooth transition path. Regards, Ceki
--
Ceki Gülcü - http://qos.ch
