+1 for varargs. We can always extend j.u.logging.Logger and add these methods.
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
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]
