On Wed, 2005-08-03 at 19:55 +0200, Joerg Hohwiller wrote: > Simon Kitching wrote: > > On Tue, 2005-08-02 at 23:02 +0200, joerg wrote:
<snip> > >>>If you were to create a bugzilla entry with an implementation of this > >>>feature and supporting unit tests [and assuming no-one else votes > >>>against it] I will review and commit it sometime in the next few weeks. > >>> > >>>Note, however, that commons-logging isn't making much progress at the > >>>moment, and several issues standing in the way of a new release. So > >>>there's no guarantee of when the next release might actually be pushed > >>>out. > >> > >>Great! This sounds like an option. > >>I wouldn't mind making the bugzilla entry and writing junit tests. > >>Maybe the two Joergs (and whoever likes this proposal) may get together > >>doing this. > >> > >>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? 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? 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... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
