avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [PATCH] Re: Cascading Configuration
Date Thu, 14 Feb 2002 06:11:21 GMT

Pete:

Something to keep in mind is to leverage the approach taken by
the current CascadingConfiguration implementation as opposed to
incorporating structural parent associations (i.e. use it as it
is).  Using the current implementation you don't have any merge
issue to deal with, you simply drill through a chain of n
configuration looking a solution.  The configuration themselves
don't change because CascadingConfiguration is an orthogonal view
... and it works really well :-).  I actually want to bring the
potential introduction of CascadingConfiguration into Phoenix.
I would like include very static default configuration inside
a block jar file (i.e. not for modification between releases),
that form defaults for the classic configurations.  It would be
trivial to implement ... new CascadingConfiguration( a, b );.

Cheers, Steve.


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Thursday, 14 February, 2002 06:28
> To: Avalon Developers List
> Subject: Re: [PATCH] Re: Cascading Configuration
>
>
> Hi,
>
> Im still not sure I am comfortable with doing the mergin this way
> rather than
> through utlity methods. The main reason is there are different
> strategies to
> use when merging consider the following
>
> Source: <a/>
> Default: <a><b/></a>
>
> The result will most likely be equal to the "Default" tree. But
> what happens
> in the following cases
>
> Source: <a><b/></a>
> Default: <a><b/></a>
>
> Do we double the B or replace it?
>
> Source: <a><b x="1"/></a>
> Default: <a><b/></a>
>
> Do we double the B or replace it?
>
> Source: <a><b x="1"/></a>
> Default: <a><b y="2"/></a>
>
> Do we double the B or replace it or merge it?
>
> Source: <a><b x="1"/></a>
> Default: <a><b x="2" y="2"/></a>
>
> Do we double the B or replace it or merge it?
>
> etc.
>
> Mergin attributes is simple and well understood but the ability
> of merging
> trees is less so - which is why we should keep it in a utility method and
> keep that in excalibur until we are more certain of it.
>
> --
> Cheers,
>
> Pete
>
> --------------------------------
> My opinions may have changed,
> but not the fact that I am right
> --------------------------------
>
> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


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


Mime
View raw message