On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

>  I see the same regression too.
>
> I further debugged the issue and found out the behavior depends the order
> how artifacts are resolved.
>
> 1) The SCADefinitions model contains the Intent and PolicySet models
> 2) The PolicySet model may reference Intent models
>
> Now say we have two definitions.xml file in the contribution, then there
> will be two SCADefinitions objects: D1 and D2. Let's assume D1 contains I1
> (Intent) and D2 contains P1 (PolicySet). P1 references I1. The current
> code resolve D1 and D2 independently.
>
> If D1 is resolved before D2, then I1 is set to resolved and P1 will be
> resolved as I1 is resolved. But if D2 is resolved before D1, the P1 cannot
> be resolved as I1 is not resolved yet. This explains why we see different
> behaviors.
>
> It seems that we will have to resolve all the Intents first before we can
> resolve PolictSets. This happens within one single SCADefinitions but not
> across more than one SCADefinitions.
>
> One hack would be to set Intent to resolved during the read phase. Or we
> merge all the definitions before the resolve. Any suggestions?
>
> Thanks,
> Raymond
>
>  *From:* ant elder <[EMAIL PROTECTED]>
> *Sent:* Saturday, July 26, 2008 4:20 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: Policy error building binding-ws-axis2, was: Error building
> binding-ws-axis2
>
>
>
> On Sat, Jul 26, 2008 at 2:38 AM, Jean-Sebastien Delfino <
> [EMAIL PROTECTED]> wrote:
>
>> Raymond Feng wrote:
>>
>>> My guess is that the message complains:
>>>
>>> With the following policySet:
>>>
>>>  <sca:policySet name="wsClientAuthenticationPolicy"
>>>    provides="tuscany:wsAuthentication"
>>>    appliesTo="//sca:binding.ws">
>>>
>>> "tuscany:wsAuthentication" is a provided intent by the policy set and it
>>> cannot find the definition of intent "tuscany:wsAuthentication".
>>>
>>> Thanks,
>>> Raymond
>>>
>>>
>> I've debugged, opened JIRA TUSCANY-2499 to track the problem and committed
>> a workaround (linked to 2499).
>>
>> --
>> Jean-Sebastien
>>
>
> The work around breaks the build for me with the error below. Backing out
> r679944 and everything is working ok in my environment.
>
> Caused by: org.osoa.sca.ServiceRuntimeException: Provided Intent - {
> http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentica<http://tuscany.apache.org/xmlns/sca/1.0%7DwsAuthentica>
> tion not found for PolicySet {
> http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationPolicy<http://tuscany.apache.org/xmlns/sca/1.0%7DwsClientAuthenticationPolicy>
>         at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.analyseProblems(DefaultSCADomain.java:309)
>         at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:334)
>         at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:183)
>         at
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.<init>(DefaultSCADomain.java:120)
>         at
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
>         ... 20 more
>
>   ...ant
>
> Looking at the code it's interesting as
ContributionServiceImp.processReadPhase() has special code to ensure that
all the intents, policy sets etc from all definitions that are found during
the read of a single contribution are added to the
policyDefinitionsResolver. However when it comes to resolve time, as Raymond
points out, the definitions.xml files are resolved independently, one at a
time. Hence successful resolution is order dependent.

It seems to me that the solution to this depends on whether we take the spec
at face value and assume that definitions.xml files that can appear in
contributions in Tuscany are logically part of "a global, SCA Domain-wide
file". Or if  these individual definitions.xml  files are subject to
contribution import/export semantics?

If the former then we need some separate domain level processing (just
before the build phase?) that does policy resolution. If the latter we need
to make sure that the policy artifacts are resolved in the correct order
across definitions files within a contribution rather than just within a
single definitons.xml file.

To me the latter seems to fit the contribution model more accurately and
hence it seems to be the more consistent of the two. Does seem to contradict
the spec though.

Simon

Reply via email to