Peter, I agree with what has been said so far.  Why would the wrapper
want to lose functionality even if I don't use it, or even if LogKit
doesn't use it?

Scott

> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] 
> Sent: Tuesday, January 29, 2002 1:04 PM
> To: Jakarta Commons Developers List
> Subject: RE: [Logging] [VOTE] Commons Logging 1.0 Release
> 
> 
> 
> 
> 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:commons-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to