----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Wednesday, April 03, 2002 4:37 PM Subject: Re: [logging] Need interface...
> 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. But that's the expectation you introduce with that interface, that components using commons-logging will implement a particular interface. > 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". Again with the strange attributions. I didn't say "I don't need it", I'm saying it introduces the expectation that other Commons components (and any other client of commons-logging) will implement it. > 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. You've misinterpreted my comments. If I think it makes implementation of commons-logging more confusing, that's a valid reason. > 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. I don't agree. I think it's confusing if some components are externally configurable and some are not. I don't think you can cleanly categorize components that need logging vs. those that don't. Either the logs are consistently assigned by package name, or they are externally assignable (possibly defaulting to package name). I don't think some combination thereof is practical. And I don't want to revisit all the components to make their Logs externally assignable. > 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]> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
