On Tue, Jul 13, 2010 at 10:00 AM, Simon Laws <simonsl...@googlemail.com> wrote:
> On Tue, Jul 13, 2010 at 5:38 PM, Brent Daniel <brenthdan...@gmail.com> wrote:
>> On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <simonsl...@googlemail.com>
>> wrote:
>>
>>>> 1) Should we be raising an error at build time when intents aren't
>>>> satisfied by some policy set?
>>>
>>> Yes
>>>
>>
>> OK. I've been working with these changes locally and will commit them soon.
>>
>>>> 2) If yes, how do we make sure extensions are considered?
>>>
>>> Not sure what this means. Do you mean when an extension provides an
>>> intent by default. If so this should be taken account of when the
>>> unsatisfied intents are calculated. There is some code for this but I
>>> can't say if it's actually working properly.
>>>
>>
>> Yes.. basically we need to check if the intent is in the
>> alwaysProvides or mayProvide attribute for the implementation type or
>> binding type. My confusion here is that there's a comment in the code
>> that says we need to walk through all extensions, but it seems like
>> all we would need to check is the extensionType on the PolicySubject.
>
> Can you point me at where the comment is in the code?
>
It's in ComponentPolicyBuilderImpl around line 522:
if (!intentMatched){
// Raise a warning as we have an intent that doesn't
have a matching
// policy set at this start.
// TODO - this could be because the intent is provided
by and extension
// and hence there is no explicit policy set.
Need and extra piece
// of processing to walk through the extension models.
// warning(context.getMonitor(),
"IntentNotSatisfiedAtBuild", subject, intent.getName(),
subject.toString());
error(context.getMonitor(),
"IntentNotSatisfiedAtBuild", subject, intent.getName(),
subject.toString());
}
>>
>> At the moment this is only affecting POL_3019 which uses the SOAP intent.
>>
>>>> 3) If no, should we be checking for this later (when we wire the
>>>> endpoints?)
>>>
>>> We need to check here also as the service binding might "provide" a
>>> reference intent.
>>>
>>
>> We're handling the reference side checking there already, so we should be ok.
>>
>>>> 4) Should we be providing additional policy sets for intents required
>>>> by the spec that allow for external attachment?
>>>
>>> No. Not for the purposed of passing the otests at least. We will of
>>> course want to provide policy sets for the spec defined intents for
>>> normal operation.
>>>
>>
>> We don't necessarily need to do this for the otests, as currently all
>> test cases that use spec defined intents either expect an exception
>> (9015,9016,9017,9018) or define a policy set that satisfies it
>> (9022,9023.) If we don't implement an externalAttachment version of
>> propagatesTransaction, then we will be checking for a failure to
>> resolve the intent rather than testing the intended function. That's
>> probably OK from an otest perspective, but not ideal.
>>
>> I was thinking more generally, though, that this is something we
>> should be providing. It doesn't seem right to mandate that users have
>> to use one flavor of attachment when our runtime supports both.
>
> Y, I agree. I think the spec allows you to provided one or the other
> but we happen to provide both. We should show examples of both in our
> samples and tests. When it comes to actual applications it's going to
> be up to the users themselves which approach they choose to take in
> each situation.
>
>>
>> Brent
>>
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
