commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Morgan Delagrange" <>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 22:12:29 GMT

----- Original Message -----
From: <>
To: "Jakarta Commons Developers List" <>;
"Morgan Delagrange" <>
Sent: Wednesday, April 03, 2002 3:04 PM
Subject: Re: [logging] Need interface...

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

Fine by me.  All I mean to refer to is externally setting the Log object.
Use whatever terminology makes you comfortable.

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

I'm not saying that we shouldn't allow you to set an external Logger because
Avalon requires it.

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

> > since we don't expect such behaviour in Commons components, it seems
> > counter-productive to support it in the logger, which would introduce
> > 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.

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.

> 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:
> For additional commands, e-mail:

Do You Yahoo!?
Get your free address at

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message