commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [logging] Need interface...
Date Wed, 03 Apr 2002 21:20:27 GMT
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net] 
> 
> 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. 

And Servlets.  You are handed a Context object--with the Context.log()
method.  You have no choice over what log level or implementation you
use.

> 
> 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.

Did you once here me say *everyone should use only IoC*?

I never said that, so don't twist words.  I said that projects
built on IoC should not have static accessors.  Granted the
impact of static accessors for a logging implementation is
low, consistency does help.

Not to mention, components can be used in different logical
sections of a system.  If your log categories are set up according
to functional unit (as is the practice in Cocoon and other
apps like it), the Logger will most likely be different depending on
which system it is used inside of.



> > > 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.


Again you missed the main point.  If you want to *allow* overriding
of a logger by another class so be it.  Don't call it IoC.
I jumped in this discussion because someone else started using the
term IoC, and I wanted to clarify the understanding around it.

Jumping to conclusions is crazy.


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message