Re: [logging] To depend or not to depend?

[Leo Simons]

robert burrell donkin wrote:

On Saturday, February 8, 2003, at 08:16 PM, Leo Simons wrote:

James Strachan wrote:

Would it be acceptable

to add a getName() or something similar to the Log interface and the
implementations? That way, we can fully implement the avalon-framework
Logger contract on top of commons-logging.

+1.
Seems reasonable to me. I guess it won't break anyones code who just use
commons-logging to log. The only risk is people who implement Log,

yep. It is a backwards-incompatible change there.

losing backward compatibility seems to me like it might open up a whole can of worms. i worry that here in the commons we'd be left with major incompatible problems between components based on the version of commons-logging that they used.

a lot of time and debate was spent on the Log interface. as far as the original idea is concerned, it's exactly right the way it is. once we start changing the original concept, when do we stop?

rather than dive in and make changes to something which took literally months of debate to get right (ie the Log interface), i'd prefer it if we could look around for a solution which would preserve backwards compatibility for this critical interface.

wouldn't it be better to either extend Log or create a Logger class which implements Log but which has the extra method(s) that leo needs?

The problem is precisely in implementing such a Logger; you need the right logger name in order to do something requiring that name. The obvious change is to change the constructor signature to

CommonsLogger( Log log, String name ) { ... }

I need to do some thinking on the impact this has on code that needs to create the loggers. Obviously, the avalon-framework Logger has a teeny weeny little bit of information exposed which Log doesn't expose, and there is no optimal route around it.

I think the new constructor is more acceptable than the change to Log, meaning the additional method is unneccessary. The silly part is that the logging name is known inside all the things Log abstracts away from, yet not available through the interface. No API is ever perfect :D

Regardless, I think adding an additional base class or interface which does provide the extra information is not a good idea: you keep the same problem where components will depend on the new release with the new interface in it.

ah, the wonderful world of spending hours deciding on a single method :D

cheers,

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]