avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@interdimensions.com>
Subject Re: [VOTE] RE: MutableConfiguration
Date Sat, 31 Jan 2004 05:43:55 GMT

alright, since I was the silly one to send when I meant to cancel :)  I'll 
continue my random thoughts..  I hope they add something.



I think the Configuration object given to the component by the container
should always be read only.  It primarily belongs to the container ( or
rather the administrator there of ), and the component has no business
mucking with that information.  I would never want a container to
overwrite my hand managed configuration files..

If a component wants to persist some information ( which it can use to
affect it's configuration/initialization/behavior later ), then that's a
separate concern from the master configuration informatin provided to it.  
For the purpose of persistance I could see a life cycle interface, which
would ask for something like a java.util.pref.Preference instance that is
tied to just that component, which it can then use to store/persist any
information that it wants to.




I also went and re-read Leo's original post about MutableConfiguration.  
And really, the only reason he wants it was so that he could write code
against the interface MutableConfiguration instead of the implementation
DefaultConfiguration.  For what he wants it, you could just think of it
as: DefaultConfigurationInterface.  If that's the case I don't feel too
scared of adding it to framework-impl.  It is just a minor refactoring
and/or generalization of DefaultConfiguration. ( though some could argue
that it's not a necessity, so why do it )

If we want to pull it out of -impl, we could go and add it to
framework-api, even though no one but containers should ever deal with
modifying configuration objects, so it should go into -spi.

Heck, for simplicity's sake, we could even take a que from java.util and
let Configuration have setter methods in it (and listeners) and be done
with this discussion.  Then we would have an UnmodifiableConfiguration
decorator, that would throw UnsupportedOperationException on all setters.





On Fri, 30 Jan 2004, Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:

> -----Mensagem original-----
> De: Fernando Padilla [mailto:fern@interdimensions.com]
> 
> 
> > I have some comments, that might 
> 
> Somebody shoot you while you was writing? :-)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message