-----BEGIN PGP SIGNED MESSAGE----- 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 added. > > 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 Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfjvamPuec2Dcv/8RAgj5AKCKREGjEZVUc42ZqcpCZwdaLVMIAQCfUXx7 237eRqQhfGeJ9i7gsRkdcY0= =4m7W -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
