----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 5:44 PM
Subject: Re: [VOTE] Promote "Logging" Proposal to jakarta-commons
> On Fri, 17 Aug 2001 08:43, Morgan Delagrange wrote:
> > ----- 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.
>
> The problem is if you specify that then you may aswell just bind directly
to
> Log4j. If the Log4j system behaves differently from all the other logging
> systems then you haven't really created a generic logging interface.
Hmm, I don't see the big deal. A String is an Object, and every Object has
a toString() method. It's common practice to accept Objects can call
toString() on them.
> > > * 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.
>
> I am not sure I understand this. I thought the point of logging interface
was
> to allow the user of component to control logging. So shouldn't the client
of
> httpclient (say SnazzyBrowser2000) be the one to specify log levels? It
seems
> kinda counter intuitive to me to have the user specify level/priority.
I would not expect this method to be used very often, but it's important for
legacy products that don't want to change their API. Otherwise you have to
remove all those setDebug() methods from the code, which means all the
dependant projects have to change _their_ code, and it's a big, big mess.
It would be much better to handle the transition between logging methods
transparently. That way, those legacy projects can enable debugging through
their old methods _or_ externally.
> > > 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.
>
> Could you outline?
I have no idea if all loggers will support this well or at all.
> > 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.
>
> true but all logging toolkits I know of do do it to some degree or
another.
What about the toolkits you don't know about? ;)
- Morgan
>
> The only one that doesn't (Syslog from protomatter) could easily imitate
it
> by doing something like
>
> return new SyslogLogImpl( currentCategory + "." + subCategory );
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> * "Faced with the choice between changing one's mind, *
> * and proving that there is no need to do so - almost *
> * everyone gets busy on the proof." *
> * - John Kenneth Galbraith *
> *-----------------------------------------------------*
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
