avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Cascading Configuration
Date Tue, 12 Feb 2002 14:21:36 GMT
Torsten Curdt wrote:
> On Tue, 12 Feb 2002, Berin Loritsch wrote:
>>Torsten Curdt wrote:
>>>Wouldn't it make sense to also have a
>>> class CascadingConfiguration extends AbstractConfiguration {
>>>   public CascadingConfiguration( Configuration conf ) {
>>>    ...
>>>So we can apply the same pattern as for the ComponentManager or the
>>>RoleManager? So you easily split configuration files...
>>? How do you see this working?
> Every lookup of values will use the usual configuation object first.
> If there is no such element the lookup is delegated to the parent
> configuration.

Keep in mind that each Container can add it's own include semantics.
That is the general rule of thumb I am using for the AbstractContainer
in the excalibur.system package.  (Man it would be sweet if we can
knock off the org.apache.avalon prefix--I say know after arguing against
it in the past :/ )

The include semantics would be something like this:

<root include="foo.xconf">

In this case, the included elements would be included as a child of the

   <xi:include href="foo.xconf"/>

In this case, the included elements would replace the <xi:include/> element.

In the latter case, using the XInclude semantics from W3C, it can be built
into the Parser object: with the <parameter name="support-xinclude" value="true"/>

Would that satisfy the requirements?

>>Seriously, the Configuration works fairly elegantly right now.  If I
>>have a child that uses a Configuration block, I send the child to it.
>>That Child Component cannot see any configurations from the parent.
> That's true is really nice right now. But it having the
> CascadingConfiguration gives us the possibility to split
> configurations over multiple file (without ugly XML entities ;)
> Should be an nice addition to Excalibur maybe?


I think what you really want is configuration including--not necessarily
Cascading Configuration objects--although that approach would enable a
template configuration tree that had defaults....


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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