You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/02/12 13:10:09 UTC
Cascading Configuration
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...
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Pete:
I'm not quite sure that "merge" and "cascading" are semantically
equivalent (maybe it is), however, I do prefer the cascading
pattern used with Context and ComponentManager (as opposed to
util.mergeConfiguration, util.mergeContext, until.mergeMananger).
In addition, the cascading configuration model executes effective
merging at a much finer granularity. Invoking getChild on a
CascadingConfiguration returns a CascadingConfiguration instance
and subsequent evaluations of values are much more constrained.
Merging would require a lot more processing at the merge point
because you have to merge n level of child element aggregation
and then take care of attribute merging as well (which I think
may have hidden problems).
Cheers, Steve.
> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> Sent: Tuesday, 12 February, 2002 21:08
> To: Avalon Developers List
> Subject: Re: Cascading Configuration
>
>
> On Tue, 12 Feb 2002 23:10, 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...
>
> I think there is two things here that you may be trying to do. One is to
> merge two Configuration trees (ie a tree of defaults and a tree of real
> values) and another may to be include one default tree in another tree.
>
> So instead of altering configuration in any way it may be best to add a
> method like
>
> Configuration mergedTree = ConfigurationUtil.merge( realTree,
> defaultsTree );
>
> and use xinclude to do the including.
>
> --
> Cheers,
>
> Pete
>
> *----------------------------------------------*
> | The best defense against logic is ignorance. |
> *----------------------------------------------*
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Re: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Torsten:
I'll take a look at the patch and run some tests against the
ORB and ORBFactory implementation.
Cheers, Steve.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Wednesday, 13 February, 2002 11:33
> To: Avalon Developers List
> Subject: [PATCH] Re: Cascading Configuration
>
>
> Here we go...
> ...it would be great if someone could look over this
> and then apply it. I changed the AbstractConfiguration
> and DefaultConfiguration as discussed before
>
> cheers
> --
> Torsten
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
> I'm having trouble building a test case for the cascading configs
> using DefaultConfiguration and AbstractConfiguration based on the
> diffs. The issue concerns the point at which a configuration
> instance is created.
>
> Here are the two use cases that I envisage - both concern the
> creation of a new configuration that is bound to an existing
> parent configuration.
>
> 1. when creating a cascading configuration from a file or
> stream using DefaultConfigurationBuilder, e.g.:
>
> builder.build( my_stream, defaultConfig );
>
> 2. when creating a cascading configuration from a
> configuration child
>
> config.getChild( "profile", defaultConfig );
I guess we need some consense about the API extension first.
The following classes are affected:
- DefaultConfigurationBuilder
- SAXConfigurationHandler
- NamespaceSAXConfigurationHandler
We somehow we need to pass the information about the parent configuration
from the DefaultConfigurationBuilder down to the SAXConfigurationHandlers.
I tend to:
- add a method setParentConfiguration(Configuration) to the
DefaultConfigurationBuilder class
- add a constructor capeable of taking a parent configuration to
SAXConfigurationHandler as well as to NamespaceSAXConfigurationHandler
Anyone a nicer sollution?
> Neither of the above cases are supported by the proposed change.
> The approach taken in CasacadingConfiguration deals with these
> cases through a target/parent wrapper approach. However, the
> attribute resolution mechanism in the updated AbstracConfiguration
> is much more elegant - but I haven't got my head around an
> appropriate resolution. Any thoughts ?
Sorry, did get where you are heading :)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] Re: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Torsten:
I'm having trouble building a test case for the cascading configs
using DefaultConfiguration and AbstractConfiguration based on the
diffs. The issue concerns the point at which a configuration
instance is created.
Here are the two use cases that I envisage - both concern the
creation of a new configuration that is bound to an existing
parent configuration.
1. when creating a cascading configuration from a file or
stream using DefaultConfigurationBuilder, e.g.:
builder.build( my_stream, defaultConfig );
2. when creating a cascading configuration from a
configuration child
config.getChild( "profile", defaultConfig );
Neither of the above cases are supported by the proposed change.
The approach taken in CasacadingConfiguration deals with these
cases through a target/parent wrapper approach. However, the
attribute resolution mechanism in the updated AbstracConfiguration
is much more elegant - but I haven't got my head around an
appropriate resolution. Any thoughts ?
Cheers, Steve.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Wednesday, 13 February, 2002 11:33
> To: Avalon Developers List
> Subject: [PATCH] Re: Cascading Configuration
>
>
> Here we go...
> ...it would be great if someone could look over this
> and then apply it. I changed the AbstractConfiguration
> and DefaultConfiguration as discussed before
>
> cheers
> --
> Torsten
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
Here we go...
...it would be great if someone could look over this
and then apply it. I changed the AbstractConfiguration
and DefaultConfiguration as discussed before
cheers
--
Torsten
Re: Cascading Configuration
Posted by Peter Donald <pe...@apache.org>.
On Tue, 12 Feb 2002 23:10, 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...
I think there is two things here that you may be trying to do. One is to
merge two Configuration trees (ie a tree of defaults and a tree of real
values) and another may to be include one default tree in another tree.
So instead of altering configuration in any way it may be best to add a
method like
Configuration mergedTree = ConfigurationUtil.merge( realTree, defaultsTree );
and use xinclude to do the including.
--
Cheers,
Pete
*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> > Do you want me to prepare a patch for the AbstractConfiguration?
>
>
> Sure--but keep in mind that you may have to do some stuff to
> DefaultConfiguration
> as well :)
You should only need to add an additional constructor.
Cheers, Steve.
p.s. Please ignore previouse query concerning AbstractConfiguration!
(brain not completely engaged yet) :-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
> > Do you want me to prepare a patch for the AbstractConfiguration?
>
>
> Sure--but keep in mind that you may have to do some stuff to DefaultConfiguration
> as well :)
Sure :)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
>>>This is already working? Ups, didn't now that...
>>>
>>No, it is the responsibility of the Container to require or allow those semantics.
>>The reason being is that not all container allow or should allow configuration
>>including.
>>
>
> Makes sense
>
>
>>>At least that would be nicer than the XML entity approach.
>>>
>>True.
>>
>
> [snip]
>
>
>>>Yes, including was it in the first place... but I now I really like
>>>this approach... I'm sure one can say it comes from the FS at the moment
>>>;) but I'm sure there some nice use-cases for this...
>>>
>>>But what I like most about it... it's so straight forward when
>>>programming... The CM does it, the RM does it, so I thought this might
>>>also be possible with the Configuration (altough it's not a Manager) but I
>>>don't think this pattern has to be tied only to Managers.
>>>
>>>Maybe it makes even more to just add another constructor to the
>>>AbstractConfiguration class and implement in there. "Cascading" _might_
>>>not exactly the right name... don't know
>>>
>>
>>I think the AbstractConfiguration with the parent constructor would be enough.
>>I think we may be doing it with Parameters as well.
>>
>
> Do you want me to prepare a patch for the AbstractConfiguration?
Sure--but keep in mind that you may have to do some stuff to DefaultConfiguration
as well :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
> > This is already working? Ups, didn't now that...
>
> No, it is the responsibility of the Container to require or allow those semantics.
> The reason being is that not all container allow or should allow configuration
> including.
Makes sense
> > At least that would be nicer than the XML entity approach.
>
> True.
[snip]
> > Yes, including was it in the first place... but I now I really like
> > this approach... I'm sure one can say it comes from the FS at the moment
> > ;) but I'm sure there some nice use-cases for this...
> >
> > But what I like most about it... it's so straight forward when
> > programming... The CM does it, the RM does it, so I thought this might
> > also be possible with the Configuration (altough it's not a Manager) but I
> > don't think this pattern has to be tied only to Managers.
> >
> > Maybe it makes even more to just add another constructor to the
> > AbstractConfiguration class and implement in there. "Cascading" _might_
> > not exactly the right name... don't know
>
>
> I think the AbstractConfiguration with the parent constructor would be enough.
> I think we may be doing it with Parameters as well.
Do you want me to prepare a patch for the AbstractConfiguration?
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
>>>>>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">
>></root>
>>
>>In this case, the included elements would be included as a child of the
>>element.
>>
>><root>
>> <xi:include href="foo.xconf"/>
>></root>
>>
>>In this case, the included elements would replace the <xi:include/> element.
>>
>
> This is already working? Ups, didn't now that...
No, it is the responsibility of the Container to require or allow those semantics.
The reason being is that not all container allow or should allow configuration
including.
> At least that would be nicer than the XML entity approach.
True.
>
>
>>>>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....
>>
>
> Exactly...
>
> Yes, including was it in the first place... but I now I really like
> this approach... I'm sure one can say it comes from the FS at the moment
> ;) but I'm sure there some nice use-cases for this...
>
> But what I like most about it... it's so straight forward when
> programming... The CM does it, the RM does it, so I thought this might
> also be possible with the Configuration (altough it's not a Manager) but I
> don't think this pattern has to be tied only to Managers.
>
> Maybe it makes even more to just add another constructor to the
> AbstractConfiguration class and implement in there. "Cascading" _might_
> not exactly the right name... don't know
I think the AbstractConfiguration with the parent constructor would be enough.
I think we may be doing it with Parameters as well.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Torsten wrote:
> Berin wrote:
> > 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....
>
> Exactly...
>
> Yes, including was it in the first place... but I now I really like
> this approach... I'm sure one can say it comes from the FS at the moment
> ;) but I'm sure there some nice use-cases for this...
>
> But what I like most about it... it's so straight forward when
> programming... The CM does it, the RM does it, so I thought this might
> also be possible with the Configuration (altough it's not a Manager) but I
> don't think this pattern has to be tied only to Managers.
Its not.
Context does it as well.
> Maybe it makes even more to just add another constructor to the
> AbstractConfiguration class and implement in there. "Cascading" _might_
> not exactly the right name... don't know
Did you mean adding a constructor to DefaultConfiguration?
(I'm not familiar with an AbstractConfiguration class).
Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
> >>>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">
> </root>
>
> In this case, the included elements would be included as a child of the
> element.
>
> <root>
> <xi:include href="foo.xconf"/>
> </root>
>
> In this case, the included elements would replace the <xi:include/> element.
This is already working? Ups, didn't now that...
> 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"/>
> parameter.
>
> Would that satisfy the requirements?
At least that would be nicer than the XML entity approach.
> >>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....
Exactly...
Yes, including was it in the first place... but I now I really like
this approach... I'm sure one can say it comes from the FS at the moment
;) but I'm sure there some nice use-cases for this...
But what I like most about it... it's so straight forward when
programming... The CM does it, the RM does it, so I thought this might
also be possible with the Configuration (altough it's not a Manager) but I
don't think this pattern has to be tied only to Managers.
Maybe it makes even more to just add another constructor to the
AbstractConfiguration class and implement in there. "Cascading" _might_
not exactly the right name... don't know
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Sent: Tuesday, 12 February, 2002 15:22
> To: Avalon Developers List
> Subject: Re: Cascading Configuration
>
>
> Torsten Curdt wrote:
> > 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">
> </root>
>
> In this case, the included elements would be included as a child of the
> element.
>
> <root>
> <xi:include href="foo.xconf"/>
> </root>
>
> 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"/>
> parameter.
>
> Would that satisfy the requirements?
That a static declaration.
CascadingConfiguration deals with dynamcially constructed configurations.
A manager can select a base configuration (e.g. based on some policy)
and suppliment this with a default configuration. You can't do that
with an include statement.
> >>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?
Or DefaultConfiguration ? :-)
>
> :/
>
> 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....
Exactly!
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Berin Loritsch <bl...@apache.org>.
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">
</root>
In this case, the included elements would be included as a child of the
element.
<root>
<xi:include href="foo.xconf"/>
</root>
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"/>
parameter.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Torsten Curdt <tc...@dff.st>.
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.
> 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?
> A Configuration != Manager, so I don't see how the cascading properties
> will solve any real needs.
Can you see now?
Actually I just hit the same wall like Marcus Crafter did recently.
Looking for a nice way for a user-xconf for Cocoon ;)
> There is something else that I want to work towards (but am not anywhere
> near ready yet), which is a ConfigurationManager--i.e. a repository for
> Configuration objects for the different types of components. That way,
> there can be two-way communication to allow a Component to rewrite its
> configuration, and the ConfigurationManager will persist the change.
Damn - that would be cool!!
But as you pointed out... this will take some time ;)
--
Torsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
[snip]
>
> 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.
>
> A Configuration != Manager, so I don't see how the cascading properties
> will solve any real needs.
The CascadingConfiguration is not a manager. It is simply a
Configuration that is backed by a parent configuration (just like
Context can be backed by a parent context, or ComponentManager
can be backed by a parent manager).
This solves some "real needs" - you can supply default information
under a parent configuration, and s subset configuration as the base
configuration. When an implementation get an attribute value, the
implementation looks at the base configuration first - if no value
can be resolved, the implementation invokes the same request on the
parent. The parent may be a classic configuration or a cascading
configuration - so basically the resolution of the attribute value
continues to a point where either a value is resolved, or, not value
is available. The second aspect of cascading configuration behaviour
concerns aggregation of child elements - get the children of a
configuration node returns the children of the base configuration
and allows the corresponding parent configuration children.
It basically allows separation of things like default values from
concrete data sets - which means elimination of duplicate
configuration data.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading Configuration
Posted by Berin Loritsch <bl...@apache.org>.
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...
> --
> Torsten
? How do you see this working?
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.
A Configuration != Manager, so I don't see how the cascading properties
will solve any real needs.
There is something else that I want to work towards (but am not anywhere
near ready yet), which is a ConfigurationManager--i.e. a repository for
Configuration objects for the different types of components. That way,
there can be two-way communication to allow a Component to rewrite its
configuration, and the ConfigurationManager will persist the change.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading Configuration
Posted by Stephen McConnell <mc...@apache.org>.
Torsten:
The only reason I didn't do that is that I didn't want to
mess with the existing Configuration class. If cascading
behaviour was introduced into DefaultConfiguration, then
yes, you could do this. If cascading semantics are
supplementary then you end up with the constructor that
takes the base and parent configuration.
Cheers, Steve.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Tuesday, 12 February, 2002 13:10
> To: avalon-dev@jakarta.apache.org
> Subject: Cascading Configuration
>
>
> 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...
> --
> Torsten
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>