On Tue, 29 Jan 2002, Waldhoff, Rodney wrote:
> Date: Tue, 29 Jan 2002 14:56:39 -0600
> From: "Waldhoff, Rodney" <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: 'Jakarta Commons Developers List' <[EMAIL PROTECTED]>
> 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).
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
