commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 22:37:43 GMT
On Wed, 3 Apr 2002, Morgan Delagrange wrote:

> I _am_ saying that this interface doesn't make me happy, because as soon as
> we introduce it people will assert something like, "Commons Component X does
> not correctly implement the commons-logging component because Class Y does
> not implement the external configuration interface."  I do not want to

Component X doesn't implement commons-logging, it just uses it.

And it was perfectly clear this is a marker interfaces, that'll just say 
that X supports runtime configuration of the logger. 

If X uses a different method to set the logger - then we have a small 

> implement that interface in other Commons components; I don't think it's
> worth it.  Therefore I don't support its introduction to the Commons logger
> component.

I do have a problem with this kind of arguments - "I don't need it, so 
nobody needs it as well".

I actually miss a lot the setDebug() model used in tomcat3 - where you can 
set debugging on a component level.  Yes, you can do the same by setting 
the property on the logger used by the component, but I think it's cleaner 
if this is part of the component configuration.

Not all programs need runtime (re)configuration - but some do, and 
the fact that you don't need it in your programs shouldn't be a valid
reson for -1. 

I think this is a general enough problem.

> I only said that, "In this particular case, [Commons component developers]
> do not require that an external framework/factory/whatever generate Log
> objects for individual classes".  I didn't say that Commons components
> should not have bean methods.  Of course they should, when appropriate.  I
> don't think logging is one of those cases.  If we add this interface, I fear
> that some components will start to adopt it internally, while others will
> not.  That's what I mean by using the interface inconsistently.

That's perfectly fine - components that need runtime changes in the log 
object will use it, those who don't will not use it.

If you want a property to be modifiable, you add a setter. That doesn't 
mean all properties must have setters, or you need a 'framework' to call 
the setters. 

Is the Logger instance something to modify ? Probably not, since it is 
just a named wrapper and you can change the object underneath. 

But having a setLogLevel() and setLogName() in a component that supports 
this is valid.


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

View raw message