I can't agree enough with using var-args for logging. Stripes has,
from the start, done something very similar to Seam. The main
difference is that instead of putting placeholders into the message,
you just provide things in the order you want appended. I find that
convenient because you basically replace +s with commas. The class
in question is here:
http://svn.sourceforge.net/viewvc/stripes/trunk/stripes/src/net/
sourceforge/stripes/util/Log.java?revision=292&view=markup
Note, that using var-args not only allows you to be more concise, but
you can also do intelligent things like use Arrays.toString to get
meaningful info for arrays etc.
Regardless of what you use underneath (commons, jdk,
PrintWriter),having a nice clean logger interface really helps keep
the framework code cleaner and easier to read.
-t
On Aug 22, 2006, at 12:22 PM, Don Brown wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
