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 problem. > 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. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
