Sorry, no coffee yet this morning.. Was mixing intents and policy sets, but the conclusion is still the same -- this code isn't correct.
Brent On Tue, Jul 27, 2010 at 8:00 AM, Brent Daniel <[email protected]> wrote: > On Tue, Jul 27, 2010 at 3:51 AM, Simon Laws <[email protected]> wrote: > >> >> 1/ A general spec question. Can you externally attach a policy to a >> component and expect it to be flowed down to the components services >> and references. Our code does this at present. > > Yes, the policy set is inherited unless there is already a mutually > exclusive policy set on the service/reference. > >> 2/ The code above determines external attachment by looking for a >> policy set that has an attachTo attribute. It doesn't check that the >> attachTo actually relates to the current element. >> 3/ It then removes elements that have no attachTo details. Again it's >> doesn't check if policy sets that do have attachTo details have been >> directly or externally attached to this element. >> >> If 1 is true we don't generally have the luxury of checking whether >> external attachment overrides direct attachment at the point at which >> the xpath is processed so it seems that we need a way of remembering >> if a policy was attached externally or directly so the removal of any >> directly attached policies can be done here. >> > > Right. My interpretation of the spec is that a policy set that is > externally attached to an element via any means results in ignoring > any directly attached policy sets. That would include the case where a > policy set is attached and then flowed down to another element. But, > regardless of how you interpret that, there's still an issue with the > current code in that it will allow a directly attached policy set to > remain as long as it has an attachTo attribute -- even if it doesn't > actually attach to anything. > > Brent > >> Thoughts? >> >> Simon >> >> -- >> Apache Tuscany committer: tuscany.apache.org >> Co-author of a book about Tuscany and SCA: tuscanyinaction.com >> >
