You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2010/07/27 12:51:12 UTC
Questions about external policy attachment
Hi
I'm looking at why ASM_10002 is now failing.
The reported cause is that a reference intent
({http://docs.oasis-open.org/ns/opencsa/scatests/200903}Fred) is not
resolved. Here's the definition of the reference...
<reference name="reference1" target="TestComponent1/Service1"
requires="test:Fred" policySets="test:PolicySet1"/>
test:PolicySet1 is actually removed from the reference because the
infrastructure thinks that there is an externally attached policy set
that overrides it. Here is the definitions.xml file...
<intent name="Fred" constrains="sca:binding" intentType="interaction"/>
<policySet name="PolicySet1" provides="test:Fred"
appliesTo="//sca:service|//sca:reference"
attachTo="//sca:service|//sca:reference">
</policySet>
So currently Tuscany sees that a policy set associated with the
reference could be there due to external attachment and tries to
remove the directly attached policy sets. There is the following piece
of code in the CompositePolicyBuilder that does this....
private void removeDirectPolicySetsIfExternalExists(PolicySubject subject,
BuilderContext context) {
boolean foundExternalPolicySet = false;
for (PolicySet ps : subject.getPolicySets() ) {
if ( ps.getAttachTo() != null )
foundExternalPolicySet = true;
}
if ( foundExternalPolicySet ) {
List<PolicySet> copy = new ArrayList<PolicySet>(subject.getPolicySets());
for ( PolicySet ps : copy ) {
if ( ps.getAttachTo() == null ) {
subject.getPolicySets().remove(ps);
}
}
}
}
This raises a number of questions..
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.
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.
Thoughts?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Questions about external policy attachment
Posted by Brent Daniel <br...@gmail.com>.
I've fixed this now, but it was hiding a test case issue in POL_4019,
so that test is failing now (in the attachTo attribute on the
"BothIntents" policy set, interface.wsdl needs to be prefixed by
"sca".)
Brent
On Tue, Jul 27, 2010 at 8:42 AM, Brent Daniel <br...@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 8:12 AM, Simon Laws <si...@googlemail.com> wrote:
>
>> Yeah, also isn't it the case that, as it's not actually checking what
>> the attachTo refers to, it could be throwing away the directly
>> attached policy when it's not required to do so?
>>
>
> Yes.. If there were two directly attached policy sets on one element
> and one happened to have an attachTo attribute that didn't match
> anything, the policy set without the attachTo attribute would be
> removed.
>
> Brent
>
Re: Questions about external policy attachment
Posted by Brent Daniel <br...@gmail.com>.
On Tue, Jul 27, 2010 at 8:12 AM, Simon Laws <si...@googlemail.com> wrote:
> Yeah, also isn't it the case that, as it's not actually checking what
> the attachTo refers to, it could be throwing away the directly
> attached policy when it's not required to do so?
>
Yes.. If there were two directly attached policy sets on one element
and one happened to have an attachTo attribute that didn't match
anything, the policy set without the attachTo attribute would be
removed.
Brent
Re: Questions about external policy attachment
Posted by Simon Laws <si...@googlemail.com>.
>>
>
> 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.
Yep, I'm with you there.
> 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.
Yeah, also isn't it the case that, as it's not actually checking what
the attachTo refers to, it could be throwing away the directly
attached policy when it's not required to do so?
>
> Brent
>
>> Thoughts?
>>
>> Simon
>>
>> --
>> Apache Tuscany committer: tuscany.apache.org
>> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>>
>
Re: Questions about external policy attachment
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 27, 2010 at 4:13 PM, Brent Daniel <br...@gmail.com> wrote:
> 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 <br...@gmail.com> wrote:
>> On Tue, Jul 27, 2010 at 3:51 AM, Simon Laws <si...@googlemail.com> 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
>>>
>>
>
:-)
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Questions about external policy attachment
Posted by Brent Daniel <br...@gmail.com>.
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 <br...@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 3:51 AM, Simon Laws <si...@googlemail.com> 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
>>
>
Re: Questions about external policy attachment
Posted by Brent Daniel <br...@gmail.com>.
On Tue, Jul 27, 2010 at 3:51 AM, Simon Laws <si...@googlemail.com> 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
>
Re: Questions about external policy attachment
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Jul 27, 2010 at 11:51 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi
>
> I'm looking at why ASM_10002 is now failing.
>
> The reported cause is that a reference intent
> ({http://docs.oasis-open.org/ns/opencsa/scatests/200903}Fred) is not
> resolved. Here's the definition of the reference...
>
> <reference name="reference1" target="TestComponent1/Service1"
> requires="test:Fred" policySets="test:PolicySet1"/>
>
> test:PolicySet1 is actually removed from the reference because the
> infrastructure thinks that there is an externally attached policy set
> that overrides it. Here is the definitions.xml file...
>
> <intent name="Fred" constrains="sca:binding" intentType="interaction"/>
>
> <policySet name="PolicySet1" provides="test:Fred"
> appliesTo="//sca:service|//sca:reference"
> attachTo="//sca:service|//sca:reference">
> </policySet>
>
> So currently Tuscany sees that a policy set associated with the
> reference could be there due to external attachment and tries to
> remove the directly attached policy sets. There is the following piece
> of code in the CompositePolicyBuilder that does this....
>
> private void removeDirectPolicySetsIfExternalExists(PolicySubject subject,
>
> BuilderContext context) {
> boolean foundExternalPolicySet = false;
> for (PolicySet ps : subject.getPolicySets() ) {
> if ( ps.getAttachTo() != null )
> foundExternalPolicySet = true;
> }
>
> if ( foundExternalPolicySet ) {
> List<PolicySet> copy = new ArrayList<PolicySet>(subject.getPolicySets());
> for ( PolicySet ps : copy ) {
> if ( ps.getAttachTo() == null ) {
> subject.getPolicySets().remove(ps);
> }
> }
> }
>
> }
>
> This raises a number of questions..
>
> 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.
> 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.
>
> Thoughts?
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Mike just pointed out to me offlline that I posted the wrong version
of the definitions.xml file toward the top of my previous post. The
proper version removes the external attachment from the policy set and
includes some, currently commented out, external attachment errors. I
am struggling to get my workspace to reflect the changes in OASIS svn
at the moment for reasons I don't quite understand at the moment.
Apologies for the confusion. It doesn't though actually change the
questions.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com