> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
