[
https://issues.apache.org/jira/browse/TUSCANY-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12895177#action_12895177
]
Mike Edwards commented on TUSCANY-3642:
---------------------------------------
OK, you make good points. I think that this is something of a corner case. If
the intents on the interface declaration are treated as being part of the
structural hierarchy, then what you say about the ignoring of intents that are
mutually exclusive would apply.
However, looking at the Policy spec, there is a section that deals with Intents
on Interfaces (section 4.10 in CD03 Rev1) that says:
a) locations where interfaces are defined and declared must be treated as part
of the implementation hierarchy (this deals with how the stuff in the
componentType gets applied to the stuff in the component configuration) -
POL40019
b) The intents from the interface definition are applied to the
service/reference element AND to the binding element(s) belonging to the
service/reference element - POL40016
This second one says that you can't simply lose the sca:confidentiality that is
on the interface document - it must be applied to both the <service/> and to
the <binding/>. So in the (updated) version of ASM_8014 we have:
<component name="TestComponent2">
<implementation.composite name="test:TestComposite66"/>
<!-- Service requires an intent test:Joe that is mutually
exclusive with sca:confidentiality -->
<service name="Service1" requires="test:Joe"
policySets="test:PolicySet2">
<!-- Uses modified Service1 interface with Confidentiality
intent attached in interface definition -->
<interface.wsdl
interface="http://test.sca.oasisopen.org/#wsdl.porttype(Service1_Intent)"/>
</service>
<property name="serviceName">service2</property>
</component>
and so the intent in the interface.wsdl must be applied to the <service/>
element, where it will clash with the attached test:Joe intent.
These rules are specific to interfaces and were designed so that "contractual"
stuff represented by the interface - including policy stuff - MUST NOT get lost
when that interface is used to build a service (or a reference). If someone
sticks an intent on an interface, we assume that they don't want that
restriction violated whereever that interface is used. Hence these specific
rules for interfaces.
> Tuscany does not evaluate mutually exclusive intents correctly where one
> intent is Qualifiable
> ----------------------------------------------------------------------------------------------
>
> Key: TUSCANY-3642
> URL: https://issues.apache.org/jira/browse/TUSCANY-3642
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Policy
> Affects Versions: Java-SCA-2.0-M5
> Reporter: Mike Edwards
> Priority: Minor
> Fix For: Java-SCA-2.0
>
>
> Where one intent is declared as being mutually exclusive with a second
> intent, but the second intent is a qualifiable intent and the exclusion
> statement names the root qualifiable intent rather than one of the qualified
> forms, then Tuscany does not flag the intents as "mutually exclusive" when
> the unqualified form of the intent appears on an element with the first
> intent.
> This was discovered with the recently updated form of OASIS testcase ASM_8014.
> This testcase defines an intent "Joe":
> <intent name="Joe" constrains="sca:binding" intentType="interaction"
> excludes="sca:confidentiality"/>
> note that this is exclusive of sca:confidentiality intent, which is
> qualifiable with confidentiality.transport and confidentiality.message the
> qualified forms.
> When a service is declared where the interface has sca:confidentiality
> applied and has test:Joe applied to the service element itself, Tuscany does
> not treat these two intents as mutually exclusive and operates incorrectly.
> Note that changing the exclude statement above to read
> "sca:confidentiality.transport" causes Tuscany to spot the mutual exclusion
> and to raise an exception. So it appears as if Tuscany is converting the
> unqualified form of the intent to the default qualified form before checking
> for mutual exclusion. This is incorrect - mutual exclusion when it uses the
> unqualified form of an intent means "excludes all forms of this intent -
> unqualified and all qualified versions".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
