commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Re: [logging] proposal
Date Sat, 06 Aug 2005 22:28:53 GMT
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
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message