-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9TmlmPuec2Dcv/8RApYjAKCaiznRCECTKwcIJpYYZ7lHC+AnKACgheDw gzB7lB/66IGGnm+RrFFnKqc= =XgYN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
