On Wed, 3 Apr 2002, Richard Sitze wrote: > In this case Geir's proposal requires (somewhere, and I admit that we don't > care where) a supporting framework to be useful. It may be that the Avalon
And I'm saying that having setters _does not_ require any framework to be useful. In Axis you have Handler.setOption() - and nothing says I can't use setOption to pass a different Logger instance to my handlers. In tomcat all properties that are user-setable have setters, and now MBeans describing them. True, you can conside Axis and tomcat and ant ( and any user application that has some configurability ) as 'frameworks'. Again, having a setter doesn't mean you can't use Logger.getLogger() - only that you can also change the logger at runtime. > If the requirement stands after the group conversation, great. If not, say > bye-bye until such time as we have a clear picture for the greater need. > > In this case, my vote would be -1 to changing commons-logging (Am I a > voting member under the new by-laws or not? I'm a committer in Axis, and > I've submitted changes to commons logging) for the reasons above. I think your -1 is as valid as any other logging commiter. However I'm not sure I agree with your argument - if you don't have a need it doesn't mean other people shouldn't solve their itches. I suppose Geir had an itch - and I believe it is a valid need. It's about runtime configuration, about management or the component. I do agree the implementation is not good - there are important issues that are not resolved, so I'll change my vote to -0. > Note also that if we introduce the "push" model, and we really desire to > remain consistent within the Jakarta community, then sooner or later we > will want to have that "push" model functional under the Avalon component > framework.... do we REALLY want to go there??? I'll repeat that they Ok, what does Avalon has to do with this discussion and why do mention it ??? Almost all Jakarta projects ( Ant, tomcat ) are using 'push' for configuration. If there's a 'framework' we should be concerned - that's JMX. But it doesn't require us to directly support it, modeler and dynamic mbeans can wrap any component - as long as it provides some runtime configurability, i.e. normal JavaBeans setters. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
