> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> Leo:
>
> Niclas does not need to veto anything because I already have.
Stephen,
still, he's a committer and *can* veto. While he hasn't done so,
he's not part of any existing consensus among some committers that
MutableConfiguration should be added. I think any reasonable
definition of consensus must mean that no committer opposes the
proposal enough to vote "No". While that wasn't a -1 veto, it
was strong enough and might become one.
> Firstly:
>
> MultibleConfiguration should not be exposed under the
> Avalon client API.
+1, but a clarification is required:
Given that in Fortress and Merlin, components can be containers,
do you mean that MutableConfiguration should just not be part
of what we now call framework-api?
> Anyway - there is perfectly valid question arising from the
> discussion.
> Should a MultableConfiguration be a Configuration
I'd say: A MutableConfiguration isa Configuration, but there
should be some way of keeping the client from casting a
Configuration to a MutableConfiguration.
So how can this be done?
1. Don't expose the MutableConfiguration interface in a
ClassLoader common to the container and the client. This
means that the DefaultConfiguration passed in by the
container will implement MutableConfiguration, but the
container and client will have different MutableConfiguration
classes loaded in their classloaders, and the client cast
will therefore fail.
2. Provide a ConfigurationProxy class that wraps a Configuration
and only implements Configuration. The container should wrap
any DefaultConfiguration passed to the client in this class.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
