avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [A5] Parameters Package
Date Sat, 15 Jun 2002 22:26:01 GMT

Berin Loritsch wrote:
> I see nothing wrong about the Parameters package as a general rule, just
> a
> couple questions:
> 1) Do we want to decouple the Parameters interface from the Parameters
> object
>    like we do with Configuration?

Advantage - alternative implementations.
Disadvantage - implemetation change on Parameters instance creation.
The advantage is nice in principal but does is justify a change that 
will impact existing code.  Based on the projects I'm aware of - the 
change would be very minor.

> 2) Are we going to explicitly declare Parameterizable and Configurable
> as mutually exclusive?

Minor correction in terminology.
Parameterizable and Configurable are currently declared as mutually 
exclusive.  Tghe question is, "are we going to enforce this", "relax 
this", or "ignore this"?

> As to #1, it would provide consistency and provide a nice way of making
> different implementations of the parameters object.  It would also
> encourage us to place the Parameters.fromProperties() and
> Parameters.fromConfiguration() methods into a ParameterUtils class.
> I am +1.

I'm leaning in that direction.

> As to #2, I believe that is what we intended to do in the first place.
> The problem is that there is no way to programatically enforce it 
> without the ContainerUtils or some other helper class. If it is
> mutually exclusive, we have to specify that in the javadocs --and say
> that if a component extends Configurable and Parameterizable the
> result is undefined.


> Something like the text below:
> "WARNING: The Parameterizable interface is mutually exclusive of the
>  Configurable interface.  If your component extends both of those
>  interfaces, the behavior is undefined.  

That is sufficient.

>  The container is free to throw
>  an exception and refuse to use your component, or to pass an object
>  in to both methods.  The object may be empty.  In short do not mix
>  these two interfaces in your components."

Above detail is going into too much detail (suggesting what may happen).
Declaring that the behavior is "undefined" is sufficient.

The question of a common approach to handling this situation by 
containers would be desirable.  I'm differentiating here between generic 
contains and custom contains.  Custom contains should be able to mix and 
match both because the custom container knows more about the components 
it is managing.  However, generic contains (Phoenix/Merlin/ECm/Fortres) 
should attempt to take uniform approach.  Possibilities include:

1. reject the component at validation stage (nasty)
2. apply configuration and bypass parameterization (preferred)
3. apply parameterization and bypass configuration
4. apply both (inconsitent unless we have a consitent approach to
    identifying a parameter description (XML) from a configuration).


Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message