commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Hohwiller <>
Subject Bugzilla Issue #36062 (was Re: [logging] proposal)
Date Mon, 08 Aug 2005 22:20:39 GMT
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.


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
> We will see how much time this process will take...
> Regards
>   Jörg

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

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


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

View raw message