commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: [Logging] [VOTE] Commons Logging 1.0 Release
Date Tue, 29 Jan 2002 21:03:57 GMT

On Tue, 29 Jan 2002, Waldhoff, Rodney wrote:

> Date: Tue, 29 Jan 2002 14:56:39 -0600
> From: "Waldhoff, Rodney" <>
> Reply-To: Jakarta Commons Developers List <>
> To: 'Jakarta Commons Developers List' <>
> Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
> > you may want to consider making the parameters
> > Strings not objects. They were made strings so that
> > you could render objects with Log4j. No other logging
> > toolkit does this. Thus if this is allowed/used you are
> > directly binding to Log4j anyway - why not use Log4j
> > directly in that case?
> What's it hurt to leave Objects in there? String.valueOf(object) is easy
> enough to do, and it supports the richer functionality provided by log4j.
> Why go out of our way to restrict functionality that's otherwise trivial to
> support?

Changing Object to String would in fact represent a loss of functionality
if the underlying logging implementation you are using knows how to deal
with Objects in interesting ways (for example, it might use reflection to
dump out all the bean properties).

> > A facade is meant to behave
> > roughly the same across toolkits and it is
> > easy enough to make it do so ;)
> toString meets those criteria, yes?

Facades should also be faithful about passing on as much information as
they can.  For cases where the underlying logging implementation supports
only strings, you can do the object.toString() conversion in the wrapper
(as we do in Jdk14Logger and LogKitLogger).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message