Hi Raymond, I did start with the write option but ended up with trouble trying to access the write methods from the Builders where the PolicySets get matched. I brought this up for discussion in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27768.html where Sebastien suggested that we move this to a 'preprocessing' phase and that how
I do understand your concerns about the dependence this brings into ContributionServiceImpl which is something I anyways planned to clean up by moving all of it to CompositeProcessor. Thanks - Venkat On Thu, Mar 6, 2008 at 6:11 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > Hi, > > I'm looking into the policy framework code. I found it very strange that > we > have some code in the ContributionServiceImpl to modify the composite file > and attach tuscany attributes to the XML document to keep the applicable > policy sets for a given PolicySetAttachPoint. The later is calculated by > applying the PolicySet.getAppliesTo() XPath. The following shows the > altered > XML: > > <component name="MyComponent" tuscany:applicablePolicySets="..." > tuscany:policySets="..." ...> > </component> > > IMO, the ContributionService should be independent of any artifact types. > Why do we need to transform the SCA composite file for the policy > validation > purpose in the contribution service? > > I understand it's a bit difficult to apply XPath for StAX streams. Can we > do > the following instead? > > 1) Use the StAXArtifactProcessor.write() method to produce a DOM > representation of the PolicySetAttachPoint so that we can apply the XPath > given by PolicySet.getAppliesTo(). > > 2) Remove the getApplicablePolicySets() in the PolicySetAttachPoint model. > The validation should be handled when we configure/build the composite. > There is no need to pre-calculate the applicable policy sets. > > Thanks, > Raymond > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
