> -----Original Message-----
> From: Torsten Curdt [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 13 February, 2002 16:04
> To: Avalon Developers List
> Subject: RE: [PATCH] Re: Cascading Configuration
>
>
>
> > For reference I've included a trace of some tests using
> > the CascadingConfiguration class (and a good excuse to do
> > a quick demo my microPhoenix pipeline processor):
> >
> > $ java -jar dist\orb-examples.jar -server org.apache.hello.HelloServer
> >
> > [DEBUG ] (manager): manager ready
> > [INFO ] (manager): processing pipeline for: server
> > [DEBUG ] (manager.server): initialize
> > [INFO ] (manager.server): getting configurations
> >
> > Here I'm printing out the number of children of the parent
> > configuration, the value of a "value" attribute on the parent,
> > and an attribute "name" of a child named "feature".
> >
> > [INFO ] (manager.server): PARENT LENGTH: 3
> > [INFO ] (manager.server): PARENT VALUE: daddy
> > [INFO ] (manager.server): PARENT FEATURE: Paris by Night
> >
> > Here I'm printing out the number of children of the target
> > configuration, the value of an "value" attribute on the target,
> > and an attribute "name" of a child named "feature".
> >
> > [INFO ] (manager.server): TARGET LENGTH: 2
> > [INFO ] (manager.server): TARGET VALUE: null
> > [INFO ] (manager.server): TARGET FEATURE: Paris by Day
> >
> > Now I'm creating a new CascadingConfiguration with target as
> > the base configuration and parent as the default fallback
> > configuration. The important this to note are:
> >
> > a) the composite length is the aggregation of the parent
> > and base elements
> >
> > b) the value attribute was null in target and the
> > resolution correct defers to the parent (inhertance)
> >
> > c) the value of the attribute "name" of the child "feature" ]
> > is retrieved from the target - demonstrating that the
> > tarrget is overriding the parent
> >
> > [INFO ] (manager.server): COMPOSITE LENGTH: 5
> > [INFO ] (manager.server): COMPOSITE VALUE: daddy
> > [INFO ] (manager.server): COMPOSITE FEATURE: Paris by Day
> >
> > [INFO ] (manager): stopping: SERVER
> > [DEBUG ] (manager.server.orb.14602493): stop
> > [INFO ] (manager): disposal: SERVER
> > [DEBUG ] (manager.server): dispose
> > [INFO ] (manager): stopping: ORB-FACTORY
> > [INFO ] (manager): disposal: ORB-FACTORY
>
> Cool! But why do you need the CascadingConfiguration anymore? With the
> provided patch this should be possible just with the DefaultConfiguration.
For a couple of reasons (a) the patched DefaultConfiguration does
not handle child aggregation, (b) it doesn't support assignment of
the parent's child as the parent of a target child when invoking getChild
(wow - that a mouthful). If you takle a look at the CascadingConfiguration
source on getChild( String ), getChildren(), etc., you will see that
befind the scenes new CascadingConfiguration instance are being created
with target/parent associations, and (c) I havn't managed to get the patched
version cascading behaviour working - (but I'm also working on other
things at the same time and can't really dig too mutch). I did want to
provide a banchmark of expected behaviour so objective are clear as we
discuss options.
> ...although with this approach you can more easily switch what is to be
> the default :-/ ...but it's another wrapper object (AFAIU)
The wrapper object doesn't bother me - but would prefer that it was
either subsumed within AbstractConfiguration (only the lines of the patch)
or hidden withing AbstractConfiguration.
Cheers, Steve.
> --
> Torsten
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
