-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Simon,
Simon Kitching wrote: > On Tue, 2005-08-02 at 23:02 +0200, joerg wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Simon Kitching wrote: >> >>>[AARGH - I hate top-posting!] >> >>mmh, whatever you may mean with that (I am not a native englishman)... > > > Top-posting is where someone replies to an email then puts their > comments *above* the stuff they are commenting on. > > Bottom-posting is where the reply goes *below* the stuff being commented > on - as you did above, and I am doing now. It means that the email makes > sense when read from top to bottom. > > The email I replied to was in the "top-posting" style so I continued > that, as mixing the two styles is *really* confusing. Actually, though, > I can live with either order as long as the contents of the email are > worth reading :-) Thanks for making this clear. > > >>>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! 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. > > A slight variant of this is to create a new interface containing just > the new methods and make all existing log adapter classes implement this > new interface in addition to the current (unchanged) Log interface. I > can't currently see anything that makes this better or worse than the > above approach. So Logger would not extend Log? For me this would be useless because the "Logger getChildLogger(String)" method would not make any sense. > > Or maybe LogFactoryImpl could have an extra method: > LogFactoryImpl.getNameOfLog(Log l) > which iterates over the entries in the instances map looking for the > object and returning its name. This wouldn't be very fast but looking up > the name for a logger wouldn't be a common operation. I guess a > bidirectional map would help that. This would then allow any Log object > to have its name retrieved as long as the standard LogFactoryImpl is > being used. It would probably be clumsy to use though. Well I try to point out in a short run why people want the "getChildLogger" method: You write a component such as a persistence-layer. Therefore you write a specification in form of an interface (or you use an existing spec. as JDO) and you write an implementation. The idea of all these Containerframeworks is that the implementation needs dependend components like a logger that again have an API as specification and an implementation. BUT the implementation should not worry about how to get the implementation of the logger. It only uses the interface and somehow magically the instance of that interface is injected from outside by the container framework. Now the point is that the component will -not surprisingly- create other objects, espc. those you might call entities. Those are not components and they are not that smart in the manner of the logic they contain BUT they might also need a logger. And that is where wo go! Since they are not managed by the framework but directly be managed by the component (our persistance layer in the example) the persistence layer needs to supply the logger to them. Now there are three ways how this can be done: 1. the same logger instance is given to the entity -> the entity will write in the same log, have the same loglevel and so on. That is often not acceptable. 2. the component has a dependency to the factory of the logger (LogFactory). This is a way to go but would make it more complicated for the component-writer. There are more disadvantages but we do not want to make it too complicated. 3. the logger instance has a method to create a child logger. The child logger will by default inherit the loglevel, have the name of the parent logger as prefix of its own name and will by default write to the same logfile. BUT -depending on the logger implementation- the logger can be configured by its name. So in an application there is only one logger implementation used and the administrator knows the configuration syntax of that logger. Our persistance layer and all its entities can run with the one logger implementation in application A and with another in application B. This is what already happens with JCL BUT: Especially this can potentially happen with different container framework implementations for A and B. If you look at point 2. you can say the only reason for this is lazyness. Well its also a bit more about design but however people are lazy and on the other hand designers want to have a perfect world. So you can see the need of getChildLogger(String) by these container guys ot there here: http://excalibur.apache.org/apidocs/org/apache/avalon/framework/logger/Logger.html#getChildLogger(java.lang.String) http://svn.plexus.codehaus.org/trunk/plexus-containers/plexus-container-default/src/main/java/org/codehaus/plexus/logging/Logger.java?rev=1323&view=auto http://dpml.net/api/dpml/transit/3000/net/dpml/transit/model/Logger.html#getChildLogger(java.lang.String) ... Please also note http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Logger.html#getLogger(java.lang.String,%20java.lang.String) http://logging.apache.org/log4j/docs/api/org/apache/log4j/Logger.html#getLogger(java.lang.String) ... So you see the need for the getChildLogger(String) method is definetly there!!! If this really happens that we have the additional Logger interface you can count on me that I will get on the mailing lists of all these container guys and try to convince them to use org.apache.commons.logging.Logger and kick out their own interface! Now the more I think about it the more I like the idea that we are currently heading towards: Have the Log untouched and add the Logger that extends Log adding the two methods. There are other people that these container prayers (I am one of them) and they will say hey a logger (Log) should only be able to log and not also be a factory for loggers. For this reason there should be another interface (LogFactory). So hey we would please both worlds!!! Further if one componets depends on Log and another depends on Logger they still might work in the same container framework (as long as it is not invasive as avalon is!). > > >>You would also like me to send patches for the exisitng implementations >>so they implement Logger instead of Log? > > >>Further I leave things like LogFactory untouched. So whoever wants to >>have these two additional methods may cast from Log to Logger if he uses >>the LogFactory. >>Is that the right way to keep things easy and have no trouble with >>compatibility? > > > > Well, I'm not wildly keen on the name "Logger"; it tends to imply > java.util.logging or log4j compatibility to me. But I don't currently > have a better suggestion. I like it and not surprisingly all the container guys created their own interface and called it Logger. > > But generally, I think you're on the right track. You will need to think > carefully about the compatibility issues though; they are very > important. The most important thing for me is to have that additional Logger interface in org.apache.commons.logging. Adding a new interface will surely not cause trouble. Now for me it would make sense if all implementations of Log would then extend Logger and implement the new methods. This will only break compatibility if someone is doing really really really really really insane reflection stuff on the Log instance! > > >>>PS: Two Joerg Schaibles? How confusing! >>> >>> >> >>My name is Jörg Hohwiller. > > > Ah. Sorry I misunderstood. > > Cheers, > > Simon Take care Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8QUsmPuec2Dcv/8RAnMEAKCOfjC0l3Q4j0SJgnmmG6bPvSy1tQCfZs6C gakYsWHAh/VW2JrkGg2u0jw= =A8p/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
