commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joerg <>
Subject [logging] proposal
Date Mon, 01 Aug 2005 19:00:33 GMT
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

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:

Then there was the discussion

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>"" + '.' + nameSuffix</code>.
 * <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
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message