commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Re: [logging] proposal
Date Thu, 04 Aug 2005 16:48:01 GMT
Hash: SHA1

Hi Robert,

robert burrell donkin wrote:
> On Wed, 2005-08-03 at 19:55 +0200, Joerg Hohwiller wrote:
> [cut.]
>>>>Just let me know if I get it right:
>>>>We add a new interface called Logger that extends Log.
>>>>That is going to have two additional methods
>>>>"String getName()"
>>>>"Logger getChildLogger(String)"
>>>>Is that right?
>>>Hmm. Methods can't be added to the existing Log interface without
>>>breaking all existing implementations of that interface, ie all logging
>>>adapter code not part of the JCL project.
>>>It would be possible to extend the existing interface as you indicate,
>>>and update all of the logging adapter classes in JCL to implement this
>>>extended interface. As long as all the APIs on LogFactory etc. still
>>>deal in the old Log interface this won't break existing code that *uses*
>>>JCL. And as long as the LogFactory/LogFactoryImpl classes always deal
>>>with Log references, *not* the extended interface, JCL will still work
>>>ok with existing log adapter classes that aren't part of JCL. However
>>>code that wants to access the name info would need to cast the Log
>>>object to the extended interface - and handle ClassCastException in the
>>>case where the log adapter class actually implements only the old
>>>interface and not the new one. That sounds ok to me - the number of
>>>places where code wants to get a Log object's name isn't huge.
>>The casting thing is NOT nice but maybe that is not the problem because
>>you would only need to do this to get an initial logger
>>and maybe that binding could be done directly by a container framework
>>that directly instantiates the implementation class.
>>There would also be the opportunity to add a LoggerFactory that extends
>>LogFactory and add a "Logger createLogger(Class)" method or so but I
>>think this is NOT neccessary.
>>The people that are using JCL now should continue using it the way they
>>did before without any trouble of incompatibility even if they have
>>their own implementation of the Log interface!
> so, the idea would be change the signature of the getLog method so that
> it returns a subinterface: is that right?
No! My suggestion is NOT to change the LogFactory at all. I do care a
lot about your compatibility issues.
Once again: I only would love to see the Logger interface that extends
Log with the two suggested methods. I would suggest to change
implementations so that Logger is implemeted rather than Log but I this
is NOT as important to me. It would only make a lot of sense to not have
an unimplemented interface lying around there.
> LogFactory would do some magic behind the scenes to provide an instance
> of the new interface even when the implementation class was only a Log.
> is that right?
No - see above.
> i'd really rather not use logger as a name BTW
>>But the ones who want to use JCL as a general API for logging that
>>allows interoperation of components from different projects
>>but can not see this happen without this additional method(s)
>>would be satisfied.
>>IoC Container guys might not really care too much about the LogFactory,
>>because this is what IoC and dependency injection is all about.
> if we are intending to offer better support for IoC then IMHO we really
> need additional documentation. the folks i've talked to about this were
> strong on the need for developers to adopt new logging idioms when
> designing for compatibility with IoC. for example, AIUI the dominant
> idiom (using a single static assignment)  doesn't play well with IoC.
> i've learnt the hard way that just adding methods causes nothing but
> hassle unless there is good documentation about their use...
The Logger interface should be well documented via javadoc.
To make the discussion a little more focused, I maybe should write a
suggestion for the Logger interface and post it to this list.

I would also provide some sections for the FAQ and documention if you like.
> - robert
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


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

View raw message