-----BEGIN PGP SIGNED MESSAGE----- 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. >> >>Yep! >>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 Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8kbBmPuec2Dcv/8RAtoGAJ9LhHwsG6LEelJGSgLs8C2+4m53tQCggQGe M3Aolf+R7yeQm/sJLER+wNk= =k/Xs -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
