on 8/14/01 5:33 PM, "Morgan Delagrange" <[EMAIL PROTECTED]> wrote:
>
> --- Jon Stevens <[EMAIL PROTECTED]> wrote:
>> on 8/14/01 5:08 PM, "Morgan Delagrange"
>> <[EMAIL PROTECTED]> wrote:
>>
>>> If it were just me, I would say, "forget it", and
>>> stick with Log4J. However, the idea of an
>> abstraction
>>> layer has grown on me a little.
>>
>> Like I said, I used to agree with you.
>>
>>> Here's the problem: I know that logging API Alpha
>>> works great for me, but if I'm trying to release a
>>> "common" component, I have to account that other
>> users
>>> may have a fancy customized configuration that
>> only
>>> works for logging API Beta. So do I alienate
>> those
>>> people, or do I try to accommodate them? Let's
>> face
>>> it, once Sun releases its API, it's going to get
>> ugly.
>>
>> Jason's excellent argument against this is that
>> Log4J provides an API to
>> allow you to plug in other logging implementations.
>> I forget the name right
>> now, but starts with an "A..."
>
> I'll assume you're being coy and mean Appender.
Actually, I wasn't being coy...I really couldn't remember...being involved
with 50 different projects and a bazillion lines of code...only so much
memory for this little brain of mine...
Yes, Appender is the right class...
> Yes, that may pan out as well. If people are willing
> to allow Log4J classes in the code, under the
> assumption that Appenders can be written for other
> APIs, that would be cool with me and I would happily
> withdraw the proposal.
That is the exact assumption.
> Some people just get a rash
> when you mention Log4J.
I know...however, it is our own dog food and creating a wrapper around our
own dog food doesn't seem necessary. Especially if it limits it in any way.
> The Logger component should perform actual logging,
> except on a very basic level. Any real logging
> logic should be delegated to Log4J, LogKit, or
> whatever.
Having written the original abstraction layers for both Turbine and
Velocity, I totally agreed with you for quite some time. However, a few
discussions with jvz convinced me otherwise.
> Regardless of how it is performed, some components
> should have logging. It's unfortunate, for example,
> to not be able to turn on logging and see where
> your DBCP is leaking connections.
Again, I agree with you.
> We either bite
> the bullet on Log4J itself or use the abstraction
> layer in our classes, which delegates to Log4J or
> whatever.
I say a (non voting) -1 to an abstraction layer because it is unnecessary in
this day and time.
> If we can get buy in on Log4J, I'm in.
That is like saying:
"If we can get buy in that the default servlet engine is Tomcat".
:-)
-jon
