Notes in-line (some to Peter, some to Torsten).
> -----Original Message----- > From: Torsten Curdt [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 27 February, 2002 13:41 > To: Avalon Developers List > Subject: Re: [PATCH] Re: Cascading Configuration > > > On Thu, 14 Feb 2002, Peter Donald wrote: > > On Thu, 14 Feb 2002 19:45, Stephen McConnell wrote: > > > Peter Donald wrote: > > > > Sent: Thursday, 14 February, 2002 08:41 > > > > To: Avalon Developers List > > > > Subject: Re: [PATCH] Re: Cascading Configuration > > > > > > > > > > > > I agreee that some form of merging of config trees is useful and > > > > whether it is done via some sort of new merging Configuration > > > > implementation or via some more explicit mechaism then it woulld > > > > still be useful. The client still sees a simple configuration tree > > > > so there does not need to be any knowledge of backend > > > > representation. > > > > > > > > However you still didn't answer my queries :) Here are some > > > > of them again > > > > > > I didn't answer them because I'm not interested in "merging" :-). > > > > Yes you are - you just choose to call it a different name - > > your explanations demonstrate that quite well ;) > > > > However what really concerns me is the non-intuitive nature of > > the merging process you propose. Namely I would not expect the lone <b/> to > > be present in result in the example > > > > Source: <a><b x="1"/></a> > > Default: <a><b/></a> > > Result: <a><b x="1"/><b/></a> This isn't intuitive because there are two distinct "merge" policies that are not being seperated in the example. One policy deals with merging attribute values, another policy deals with child aggregation. On attribute merging on chiled "b" you get: Source: <a><b x="1"/></a> Default: <a><b/></a> Result: <a><b x="1"/></a> ... and a practical usage example is setting default priority to 0, and overriding this default attribute value with 1 (see apps/enterprise/orb for real work case) For content aggregation for children anmed "b" you get: Source: <a><b x="1"/></a> Default: <a><b/></a> Result: <a><b x="1"/><b/></a> ... and a practical usage example is declaring a set of <initializer class="abc"/> elements in a default configuration, and providing the ability to add additional initalizer element <initializer class="xyz"/> in an application configuration The resulting set of initializers fired up by the application is: <initializer class="abc"/><initializer class="xuz"/> (see apps/enterprise/orb for real work case) > > Even worse was this example > > > > Source: <a><b x="1"/></a> > > Default: <a><b x="2" y="2"/></a> > > Result: <a><b x="1" y="2"/><b x="2" y="2"/></a> For attribute resolution on child "b" you would get: Result: <a><b x="1" y="2"/></a> For content aggregation for children named "b" you would get: Result: <a><b x="1"/><b x="2" y="2"/></a> > > There is also no mechanisms in place for element removal. Nor > > non-cloning of default elements or of ... Application use-case does not call for this. > > When you said > > > > > I do think we should consider management! > > > > I agree which is why I dont like the proposal. It is inflexible and > > non-intuitive ;) It meets real needs and worsk really well! It handles both policies described above without dificulty and without compromising the base configurationi information. > ...sorry, I was locked in a dark room getting some work done;) Welcome back! > Anyway - back to problem then... or did we come up with flexible and > intuitive sollution yet ;) My take on the issue is that it is *very* difficult to come up with a flexible solution if the parent (default-source) is structurally bound to the nominal configuration. The CascadingConfiguration implementation bypasses this issue because it is always resolving values based on traversal of configuration layers. The enables (a) consistent and clear attribute value resolution, (b) unambiguous child lookup, and(c) child aggregation. So far, I can't see haw that level of flexibility can be achieved when the parent is structurally associated (as opposed to dynamically resolved). > ok... let's discuss the desired behaviour on a more concrete > example first: > > Source: > <cocoon version="2.0"> > <xml-parser class="my.JaxpParser" logger="core.xml-parser"> > <parameter name="validate" value="true"/> > <parameter name="namespace-prefixes" value="true"/> > </xml-parser> > <mycomponent> > config > </mycomponent> > </cocoon> > Default: > <cocoon version="2.0"> > <xml-parser class="org.apache.avalon.excalibur.xml.JaxpParser" > logger="core.xml-parser"> > <parameter name="validate" value="false"/> > <parameter name="namespace-prefixes" value="false"/> > <parameter name="stop-on-warning" value="true"/> > <parameter name="stop-on-recoverable-error" value="true"/> > </xml-parser> > </cocoon> > Result: > <cocoon version="2.0"> > <xml-parser class="my.JaxpParser" logger="core.xml-parser"> > <parameter name="validate" value="true"/> > <parameter name="namespace-prefixes" value="true"/> > <parameter name="stop-on-warning" value="true"/> > <parameter name="stop-on-recoverable-error" value="true"/> > </xml-parser> > <mycomponent> > config > </mycomponent> > </cocoon> This is the result I would expect when resolving attribute values of a named child. It is not the result I would want when requesting child aggregation (because an attribute values on a child should not be used as a convergence factor in aggregation). > I think this looks pretty straight forward - unfortunately this seems to > be quite tricky... let's look at the parameters > > What would happen if we had: > > Source: > <cocoon version="2.0"> > <xml-parser class="my.JaxpParser" logger="core.xml-parser"> > <parameter name="validate" value="true"/> > </xml-parser> > <mycomponent> > config > </mycomponent> > </cocoon> > Default: > <cocoon version="2.0"> > <xml-parser class="org.apache.avalon.excalibur.xml.JaxpParser" > logger="core.xml-parser"> > <parameter name="namespace-prefixes" value="true"/> > </xml-parser> > </cocoon> > > Of course we would expect as result: > > <cocoon version="2.0"> > <xml-parser class="my.JaxpParser" logger="core.xml-parser"> > <parameter name="validate" value="true"/> > <parameter name="namespace-prefixes" value="true"/> > </xml-parser> > <mycomponent> > config > </mycomponent> > </cocoon> Correct - if you are applying aggregation on the "xml-parser" node. But its inconsistent if your assuming this is across the abord aggreegation becuase if you were you would be creating two "xml-parser" elements under a single "cocoon" element! > But couldn't it also be: > > <cocoon version="2.0"> > <xml-parser class="my.JaxpParser" logger="core.xml-parser"> > <parameter name="validate" value="true"/> > </xml-parser> > <mycomponent> > config > </mycomponent> > </cocoon> Correct if you are applying attribute lookup. > > The default value for attribute "name" is "namespace-prefixes" it then > gets overidden and "name" gets value "validate". So only because we know > the context and therefor what there is (let say) the unique path to the > node we can tell if the attribute "name" is to be overidden or a new > "parameter" node needs to be created. > > Actually I have no idea yet to solve this... anyone else? Yep - don't use structural binding between the target and the default. Instead use dynamic resolution and you immediately simplify the problem. http://home.osm.net/doc/orb/org/apache/orb/CascadingConfiguration.html Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
