commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: [logging] proposal
Date Tue, 02 Aug 2005 08:00:28 GMT
[AARGH - I hate top-posting!]

I'm not opposed to this proposal. Commons-logging already creates a
proxy Log object for each underlying real logger object, so at the worst
the name can be remembered at the Log object level as far as I can see.
In other words, this functionality should be possible to implement
whatever the underlying logging library. 

And I'm generally convinced by the emails to this thread that all
reasonable logging libraries provide a way for logging objects to return
their name anyway.

I don't personally have any need for this feature, but it seems that
people with reasonable credentials do.

So overall I'm in favour of some kind of implementation of this feature.
Commons-logging needs to be *very* careful about adding features to its
API but this seems to me like one that passes the necessary tests.

If you were to create a bugzilla entry with an implementation of this
feature and supporting unit tests [and assuming no-one else votes
against it] I will review and commit it sometime in the next few weeks.

Note, however, that commons-logging isn't making much progress at the
moment, and several issues standing in the way of a new release. So
there's no guarantee of when the next release might actually be pushed
out.

Regards,

Simon

PS: Two Joerg Schaibles? How confusing!


On Tue, 2005-08-02 at 08:12 +0200, Jörg Schaible wrote:
> Hello,
> 
> just to complete this, I requested this some time ago also:
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg52438.html
> 
> ... and no, joerg and me only share the name, not the instance <g>
> 
> - Jörg
> 
> 
> joerg wrote on Monday, August 01, 2005 9:01 PM:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi there,
> > 
> > I have a request on the commons-logging API and I did not put
> > it on the subject to not hit your mailfilters :)
> > 
> > Yep, you guessed it - it's the "getChildLogger(String)" thingy.
> > 
> > First of all commons-logging, like other commons subprojects,
> > aims to be a library to avoid having the "reinvent-the-wheel"
> > effect so many projects can benifit using that single logging
> > API and building a large community. I hope I see this right :)
> > 
> > In general commons-logging does a good job and I can
> > perfectly aggree with the loglevels defined by
> > commons-logging and with every method available in the Log
> > interface (I could not do this for the JDK Logging "API").
> > 
> > What I am missing is the simple "getChildLogger(String)"
> > method. And I am not the first and the only one out there:
> > 
> > ####
> > So the last time it was proposed seems to be 23 Apr 2004:
> > http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/2
> > 00404.mbox/%3c40893BD6.90208@apache.org%3e
> > 
> > Then there was the discussion
> > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg
> > 17177.html esp.
> > http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg
> > 17204.html 
> > 
> > The thread died because people worried about compotibility. ####
> > 
> > Besides the references in those threads there are many more
> > projects that defined their own Log(ger) API (e.g. plexus to
> > mention another) simply because the lack of the
> > "getChildLogger(String)" method.
> > 
> > So the result is that you write your code according to one
> > logging API and can not embed that code (library, component,
> > or whatever it may be) in the next project because there a
> > different Logging API is used.
> > 
> > JAVA is cool but when classpaths become of political interest
> > I wish back the good old smalltalk days ;)
> > 
> > So all I want is that more projects are using
> > commons-logging. Isn't that your interest, too?
> > 
> > So give me another try:
> > 
> > If you do not like to break compatibility, simply add another
> > interface called "org.apache.commons.logging.Logger" (this
> > would also give it a nicer name :) ).
> > 
> > Give it the method
> > 
> > /**
> >  * This method creates a new child logger.
> >  * The name of the child logger will be
> >  * <code>current-name + '.' + nameSuffix</code>.
> >  *
> >  * @param nameSuffix
> >  *          the postfix for the name of the child logger to create.
> >  *          It must have a {@link String#length()} greater zero.
> >  * @return the new logger
> >  * @throws IllegalArgumentException if the given name has a  */
> > Logger getChildLogger(String nameSuffix);
> > 
> > This would make many people happy.
> > 
> > Not as important but even nicer would be to also have a method
> > 
> > /**
> >  * This method gets the name of this logger.<br>
> >  * Best practice is to use package-names or even classpaths
> >  * as name for a logger.
> >  *
> >  * @return the loggers name.
> >  */
> > String getName();
> > 
> > BTW then you could change the line above from
> >  * <code>"this.name" + '.' + nameSuffix</code>.
> > to
> >  * <code>{@link #getName() name}  + '.' + nameSuffix</code>.
> > 
> > Now If you still want more, I would like to see generic methods as
> > 
> > void log(Loglevel level, Object message);
> > void log(Loglevel level, Object message, Throwable cause);
> > boolean isLoglevelEnabled(Loglevel level);
> > 
> > Where Loglevel is a typesafe enum containing the 6 available
> > loglevels (I will leve it open for now if that's gonna be a
> > jdk5.0 enum). If you want I could send you a full-featured
> > and full-documented Logger Interface.
> > 
> > Now, if that was too much, just add the single
> > "getChildLogger(String)" method. You may modify the javadoc
> > according to your needs and wishes. You may even do NOT touch
> > your implementation and anything else in commons-logging to
> > make me really happy. People could write their own
> > implementations (which would still be silly) but the code
> > using the API would be reusable with another implementation
> > (esp. one of the millions of IoC or whatever frameworks out there).
> > 
> > Just this single method eigther in Log or in Logger.
> > 
> > What do you think?
> > 
> > Best regards
> >   Jörg
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> > 
> > iD8DBQFC7nFRmPuec2Dcv/8RAuIrAJ0elWFO3UbsI7gG7IoWBF/dmf7FVwCfbsmq
> > voGbNjp73fbCdIFoXIe1Z84= =NLJW
> > -----END PGP SIGNATURE-----
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message