commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Re: [logging] What's needed for a release
Date Fri, 18 Nov 2005 20:38:50 GMT
Hash: SHA1

Jörg Schaible wrote:
> Hi Robert,
> robert burrell donkin wrote on Saturday, November 12, 2005 2:00 PM:
> [snip]
>>>* Consider Joerg Schaible/Joerg Hohwiller's "getChildLogger"
>>>proposal. I'm tempted not to include this, though. Getting a release
>>>out is probably the highest priority.
>>IMHO i need to be certain that everything's exactly right
>>before i'm willing to commit it. i was trying to work through
>>the issues and making sure i understood them but this went a
>>bit quiet.
>>either of the two Joerg's around to advocate it's inclusion?
> My original proposal was to add getName to the Log interface, but I used it to create
a "getChildLogger" functionality. Joerg Howiller added a new LogFactory interface extending
Log to ensure backward compatibility, where this new functionality and other things have been
> To use the new functionality I have to cast every Log instance, but since I might also
have to deal with an implementation of another party, I cannot rely on it. So for my personal
use case, this solution is also not appropriate, since in such a case I still have no valid
fallback. I understand now, that my naive first proposal would backward break compatibility
I would rather wait for a 2.0 version of JCL to add this. That version might break compatibility
anyway (and might therefore also need new package names).
> - Jörg
Hi there,
am still a little busy on other projects and private stuff but I am still on it.
I am very keen on the issue (my proposal) but I definitivly agree that
small steps (first a release without such new stuff and then take some time
to think where we are definitvily going for the long run) makes sense.

To say it once again and clearly now:
My vision is an alternative usage of log4j. I do not like the LogFactory and all
the CCL stuff that causes so much trouble. But alternative also means for me
that the current way JCL is used will of cause remain, be supported and may
still be the suggested one (not suggested by me but maybe by the majority).

I simply imagine of a way to get an initial instance of the new Logger interface
in a software-component. To create sub-loggers I would use the getChildLogger
method. The software-component itself does not know and matter where the
Logger instance comes from. It will automatically be injected by a
IoC-Container-Framework or in a JUnitTest, ....
The Framework may decide if it only creates an initial Root-logger and itself
uses the getChildLogger or wheter it has a LogFactory to create every instance
by its name.
The important fact is that currently IoC Frameworks force me to use their own
propritary logging API (best example is/was avalon) or to do wired configuration
stuff (best example is spingframework) just to get a logger for the component. I
see a future of programming where all the various open-source projects out there
produce software components that can be integrated easily. Currently I end up
with various logger implementations and also various logfiles for one huge
open-source application build out of many libraries and glue-code. That sucks!
In business administrators say in such cases that open-source software is more
expensive than commercial software that is integrated by design.

We need a standard logging API!
For me this can potentially only be commons-logging. But as we have seen
me and many others (also many people not names Jörg) require a little extended
API. I am willing to keep on the discussion if someone has questions about or
other (better) suggestions than my proposed Logger interface.
Just to let you know: I know projects in open-source and in business that
decided not to settle on JCL because of the wired CCL stuff in LogFactory.
With my proposal JCL will also increase focus on being used/seen as an API
and not as a library. The API!

Kind 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