On Wed, 3 Apr 2002, Morgan Delagrange wrote: > > Please move the discussion about IoC and Avalon to avalon-dev. > > I'm sorry if this is such a politically charged term for you. I'm merely > referring to the practice of externally generating a class' Log object. > Call it what you like.
The practice of allowing an external class to set the log object is pretty standard since Beans were used the first time. The practice of forcing all components to use setters and not allowing pull is specific to Avalon. Jumping from 'allowing a component to be managed by having a setter' to 'all compoents should be configured only with setters and everyone should use only IoC' is what I don't like in this context. > > Most of the components implement Beans patterns and should support > > runtime changes to config ( JMX or not ). That has nothing to > > do with any inversion of control, it's standard java. > > In this particular case, we would not implement this interface in our > components, because we do not require that an external > framework/factory/whatever generate Log objects for individual classes. And Yes, we do not _require_ an external 'whatever' to generate and set the Log objects. But that doesn't mean we shouldn't _allow_ 'watever' to set or change the Log object. That's the difference. Not _allowing_ this because some other project is forcing everyone to use only this pattern is a bit crazy. > since we don't expect such behaviour in Commons components, it seems > counter-productive to support it in the logger, which would introduce the > possibility of such an interface being used inconsistently. Not sure why you wouldn't expect it - Ant, Tomcat ( all versions ), Axis, etc are all essentially based on the JavaBeans patterns. Tomcat is now going even deeper into this with JMX support, and many discussion on ant sugest more 'configurability' for components is desired. I'm also not sure what 'inconsistent' use means for you - I think ant, tomcat and most other projects I know are consistently using the bean methods, togheter with JNDI and other pull patterns. It may be 'inconsistent' from Avalon perspective, but that doesn't mean we shouldn't use it. We don't claim to support IoC. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
