avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: RE: [VOTE] RE: MutableConfiguration
Date Thu, 29 Jan 2004 19:49:38 GMT

> From: Hamilton Verissimo de Oliveira (Engenharia - SPO) 
> [mailto:hamilton.oliveira@agenciaclick.com.br] 
> There is not to stop the "client" from holding the 
> Configuration instance in a member field and change it as 
> he/she wishes.

The container can make a MutableConfiguration read-only, or
intercept any calls through the interface. Thus, there's a lot
that can be done to keep a component from changing a
at a time when it shouldn't.


The question here isn't whether there's some loophole in the Java
security model, or what damage a malicious client can do with a
MutableConfiguration - the question is whether your model of allowing
updates to a MutableConfiguration throughout the component's life
requires an interface change, or if it can be solved in the impl.
I think it can be solved in the impl.

We agree on this:

 1. The MutableConfiguration interface is passed from container to

 2. The component accesses the MutableConfiguration interface, and
    doesn't know what the real impl class is.

 3. The container know the impl class of the MutableConfiguration being
    passed to the component.

 4. The only actor changing the configuration is the component.

Due to (1), (3), the container can add listeners or whatever,
of the functionality exposed by the MutableConfiguration interface.

The only reason for having listeners in the interface (2) would be so
the component can know when it itself has made a change, after all,
nobody else is making any changes (4).

So just what is your use case for these listeners?


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

View raw message