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
Cheers, Steve.
> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 13 February, 2002 14:58
> To: Avalon Developers List
> Subject: RE: [PATCH] Re: Cascading Configuration
>
>
>
> 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:[EMAIL PROTECTED]]
> > 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
