Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of Seam's logging class
that utilizes varargs to reduce the need for isDebugEnabled().
http://docs.jboss.com/seam/latest/reference/en/html/concepts.html#d0e2598
Don
Bob Lee wrote:
How is j.u.logging overkill, especially considering using it would
mean one
less dependency? From our standpoint, the only thing we care about is
Logger
anyway.
Bob
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd rather use java.util.logging than commons-logging, but I think both
are overkill for a library. I think Nathan is spot on and we should
look to using Velocity's logging classes, imported into our codebase.
The whole logging "framework" we'd need would be like two or three
classes.
Jarjar would also be nice, perhaps in conjunction with Velocity's
logging classes. It would help us solve the xwork version problem
nicely.
Don
Bob Lee wrote:
> On 8/22/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>>
>> Say, wasn't there a mention of some package that renamed packages
>> dynamically or something? That's the real issue. Two versions of the
>> same package name on the same classpath.
>
>
> jarjar
>
> In the case of logging though, we should just use java.util.logging.
>
> If you still want to use log4j, why not write a j.u.logging Handler
which
> logs to log4j? Do we really need an API to decouple us from an API
which
> decouples us from a logging implementation, or is one level of
> indirection
> sufficient? This is why everyone makes fun of clogging.
>
> Bob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
