Ok, let me go try this and post back. I'd like to vary this a bit - but let me have some code to talk about.
Meanwhile, I did get ahead with my proposal but did not quite like the way I had to pass the CompositeProcessor all the way from the Runtime down to the builders. It seemed very hacky. - Venkat On Feb 6, 2008 5:54 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > >> Jean-Sebastien Delfino wrote: > >> Reading the composite file / building its model / re-writing it to > >> finally apply the xpath sounds very complicated. > >> > >> As an application developer I'll write the appliesTo xpath to match > what > >> I see in a composite XML file. Why can't we simply run the xpath on > that > >> original XML file before doing all the other steps? > >> > > Venkata Krishnan wrote: > > > > We will not be writing the entire composite, but only a fragment that is > the > > parent of the intentAttachPoint. Here is what the spec says : - > > > > 283 ..................................................Note that the > XPath > > expression will always be evaluated > > 284 within the context of an attachment considering elements where > binding > > instances or > > 285 implementations are allowed to be present. The expression is > evaluated > > against the parent element > > 286 of any binding or implementation element. > > .......................................................... > > > > But then, it seems like we may have to look beyond the immediate parent > or > > maybe the entire composite if your proposal is to be taken. > > Yes, but it's not incompatible. Here are some examples: > appliesTo="binding.ws" > appliesTo="[EMAIL PROTECTED]'AccountService']" > appliesTo="../[EMAIL PROTECTED]'AccountServiceComponent']" > > appliesTo="/[EMAIL PROTECTED]'bigbank']/[EMAIL > PROTECTED]'AccountServiceComponent']" > > By default you are in the parent of a binding or implementation, but can > use .. or / to go up. > > > I'd like to hear some perspectives from the specs folks on this. > > > > Now, getting to your question more specifically on why this must be done > > post-build phase, here it is.... > > - Firstly we need the PolicySet definitions to get hold of the > > 'appliesTo'. > > - For PolicySets that are specified in the composite, they are resolved > > during the resolution phase. > > - For those that have to be calculated based on the Intents specified, > > there needs to be a complete assembly model that is wired, since we also > > need to take into account the target's intents. This wiring is being > done > > on the 'wireComposite' method of the CompositeWireBuilder. > > - So the calculation of PolicySets is pushed to this point i.e. its > being > > done as part of the 'wireComposite' method, the moment the model has all > its > > connections resolved. > > - Only after the PolicySets are calculated, do we have a handle on the > > 'appliesTo' attribute of the PolicySets. > > > > How about this: > load the definitions.xml files declaring policySets. > for each policyset > prepend /*/*/ to its appliesTo xpath > for each composite XML file > run the xpath expression against the file > for each matching element > add the policySet to an imaginary "applicablePolicySets" attribute > end > end > end > > Then later when you run the composite processors, builders etc, use the > intents + policySets + applicablePolicySets attributes to figure the > effective policySets. > > This should provide the best of both worlds: > - xpath expressions evaluated against the real authored XML artifacts > - support for the intent/policySet matching algorithm from the spec > > Makes sense? > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
