-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again,
so is everybody only waiting for the complete patch on JCL or are there further discussions... Maybe you only had a nice and quiet weekend, however :) If you agree, just let me know and I will submit the hole thing. As promised I would write FAQ entries. E.g "Why is LogFactory returning Log instead of Logger?", "Why is there Log AND Logger?" and something about "JCL and IoC". Feedback most welcome. Regards Jörg Joerg Hohwiller wrote: > Hi there, > > Simon Kitching wrote: > >>>[AARGH - I hate top-posting!] >>> >>>I'm not opposed to this proposal. Commons-logging already creates a >>>proxy Log object for each underlying real logger object, so at the worst >>>the name can be remembered at the Log object level as far as I can see. >>>In other words, this functionality should be possible to implement >>>whatever the underlying logging library. >>> >>>And I'm generally convinced by the emails to this thread that all >>>reasonable logging libraries provide a way for logging objects to return >>>their name anyway. >>> >>>I don't personally have any need for this feature, but it seems that >>>people with reasonable credentials do. >>> >>>So overall I'm in favour of some kind of implementation of this feature. >>>Commons-logging needs to be *very* careful about adding features to its >>>API but this seems to me like one that passes the necessary tests. >>> >>>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. > > It might be a little noisy to the list but I want all involvement on the > process and not just dumping "my suggestion" and say "eat it or not". > Anyways the issue is opened (#36062 - for those who filter the bugzilla > mails :)) and the suggested Logger interface is attached. > I'd like to have an open discussion about: > -what will happen to LogFactory - since it is no interface we would be > safe to add a new "getLogger" method or change the "getLog" signature > from "Log" to "Logger". The signature of the "getInstance" method may > not be changed without breaking compatibility. So as already pointed out > by robert the LogFactory would need to do "something magically" behind > the scenes if the instance returned by getLog would not already > implement the Logger interface. > So I'd rather suggest not to change the LogFactory. The Logger interface > aims to fulfill enhanced requirements. "Regular users" may still use the > LogFactory as is. If they use the JCL implementation they might > themselves cast from Log to Logger but maybe in most cases this is not > required because Log fulfills their needs. Now the log-factory solves > the binding of the specification (the logger interface) to the > implemetation using the classical factory design pattern. In case of a > container framwork this is a major issue of the framework itself and I > say it clear: such IoC container framework will never ever use the way > the LogFactory works to solve the binding issue. All they need is a > specification interface and one or many implementations fullfilling the > spec. In the configuration of the framework the binding is set. > Additionally the way the LogFactory deals with classloaders may not be > applicable for some frameworks! Anyways some IoC prayers call these > good old design patterns (E. Gamma & Co.) a crime to human mankind :) > > -how about the idea to have an abstract class implementing the Logger > interface but doing nothing else. The Logger interface will say in its > javadoc that this class should be extended rather than implementing the > Logger interface. This will cause less trouble if -however- in future a > new feature request for the logger API arises. > >>>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. > > We will see how much time this process will take... > >>>Regards, >>> >>>Simon > > Regards > Jörg - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC99q3mPuec2Dcv/8RAgqoAJ9cSvyLpTgiC3K1P3j+a2Hi30piygCfYjCQ ZA82T46XLANW+HcTpQRmO+E= =Owop -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
