----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 4:05 PM
Subject: Re: [VOTE] Promote "Logging" Proposal to jakarta-commons
> Hi,
>
> I am not sure if my vote counts but I wouldn't have a problem if a few
> changes were made. Namely
> * change all the Object parameters to strings (few logging toolkits deal
> natively with objects).
What if we specified in the Javadocs that most logging implementations will
just call toString() on the Object? You're probably right that few logging
tools deal with objects, but I know Log4J can via custom appenders.
> * remove set/getLevel and all level constants. (This will be dealt with by
> implementors system ie Log4j, LogKit, Logging JSR, LogV2)
This is here to support implementations that still use explicit setDebug()
methods (like httpclient). Otherwise we would have to require an interface
change.
> * extend the is<priority>Enabled to all prioritys and not just info/debug
Hear, hear. Rod was talking about doing that.
> I would also lobby for the addition of something like
>
> Log getChildLog( String subCategory );
>
> So just say you had a logger named "foo" and you called log.getChildLog(
> "bar" ) this would return "foo.bar" category/logger.
This could cause performance problems on loggers that don't do it
efficiently. Also it's possible that loggers won't support it at all. The
only current requirement of the Logging component is a String name for a
logging category; this is not guaranteed to be a parseable hierarchy.
- Morgan
>
> All those features would earn a +1 if it still counts.
>
> --
> Cheers,
>
> Pete
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
