On Tue, Jul 13, 2010 at 7:46 PM, Brent Daniel <[email protected]> wrote: > On Tue, Jul 13, 2010 at 10:00 AM, Simon Laws <[email protected]> > wrote: >> On Tue, Jul 13, 2010 at 5:38 PM, Brent Daniel <[email protected]> wrote: >>> On Tue, Jul 13, 2010 at 4:58 AM, Simon Laws <[email protected]> >>> 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 >> >
Ok, thanks for the pointer Brent I see it now. As you say it would seem sufficient to check the extension in question to see if it "provides" the intent. The question here is which extension are we talking about. This code in the ComponentPolicyBuilderImpl is provided with a policy subject which in this case is either an Endpoint or and EndpointReference. So the extension in question will, I believe, be the binding that these refer to. There is still an issue here though. That is that the EndpointReference may not have a matched binding until runtime so we need to make sure that the build processing doesn't bail out with unresolved intents in this case. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
