Hi Sebastien, am working on this and should be done today. Am just about taking a bit of time to fit this into our existing ContributionService implementation.
- Venkat On Feb 6, 2008 12:49 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > 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] > > > > >
