commons-dev mailing list archives

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

----- Original Message -----
From: <costinm@covalent.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
"Morgan Delagrange" <morgand@apache.org>
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
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.

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

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

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

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:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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