You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/07/26 01:39:37 UTC
Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Raymond Feng wrote:
> Can you try this patch?
...
Sorry, it didn't fix it. I'm not too surprised as the error below says
the problem is a "provided" intent cannot be found (while your patch was
trying to "apply" an intent).
However I'm just guessing as I'm a little confused by the error message
and the policy definitions in the failing test case.
>> org.osoa.sca.ServiceRuntimeException: Provided Intent -
>> {http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found
>> for PolicySet
>> {http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
--
Jean-Sebastien
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Raymond Feng <en...@gmail.com>.
Let's go ahead to make 1.3 release without any actions to TUSCANY-2499. We'll continue the discussions around the policy stuff and hopefully we'll come out a better solution for future releases.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, July 28, 2008 11:44 AM
To: dev@tuscany.apache.org ; antelder@apache.org
Subject: Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
On Mon, Jul 28, 2008 at 7:39 PM, ant elder <an...@gmail.com> wrote:
On Mon, Jul 28, 2008 at 7:33 PM, Simon Laws <si...@googlemail.com> wrote:
On Mon, Jul 28, 2008 at 7:02 PM, Ramkumar R <ra...@gmail.com> wrote:
Hi Ant,
I believe, this issue cropped up due to a fix provided through TUSCANY-2354, this issue did not exist before in 1.2 release as the code did not do proper validation to ensure that all the intents and policysets are resolved. TUSCANY-2354 came up with a fix as to resolve all the simple intents first and then simple policysets and then the referred policysets and so on, which i believe worked for most of the validation.
Currently, I am able to resolve this issue by applying this patch.... (reason: a confilict exist wsClientAuthenticationPolicy)
Index: modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
===================================================================
--- modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (revision 680260)
+++ modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (working copy)
@@ -37,7 +37,7 @@
</tuscany:wsConfigParam>
</sca:policySet>
- <sca:policySet name="wsClientAuthenticationPolicy"
+ <sca:policySet name="wsClientAuthenticationPolicy2"
provides="tuscany:wsAuthentication"
appliesTo="//sca:binding.ws">
<tuscany:wsConfigParam>
Index: src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
===================================================================
--- modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (revision 680260)
+++ modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (working copy)
@@ -41,7 +41,7 @@
<reference name="helloWorldWS" />
</component>
- <reference name="helloWorldWS" promote="HelloWorldComponent/helloWorldWS" policySets="tuscany:wsClientAuthenticationPolicy">
+ <reference name="helloWorldWS" promote="HelloWorldComponent/helloWorldWS" policySets="tuscany:wsClientAuthenticationPolicy2">
<interface.wsdl interface="http://helloworld-om-uri#wsdl.interface(HelloWorld)" />
<binding.ws wsdlElement="http://helloworld-om-uri#wsdl.binding(HelloWorldSoapBinding)"
uri="http://localhost:8085/myExplicitURI"/>
Can anyone try this and let me know if this works.
NOTE: I also strongly believe that we need to address the issue of treating the definitions.xml as global to SCA domain, and try to resolve the policy artifacts once all the policy definitions are loaded.
On 7/28/08, ant elder <an...@gmail.com> wrote:
On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <js...@apache.org> wrote:
Simon Laws wrote:
On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com <ma...@gmail.com>> 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 <ma...@gmail.com>
*Sent:* Saturday, July 26, 2008 4:20 AM
*To:* dev@tuscany.apache.org <ma...@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
<jsdelfino@apache.org <ma...@apache.org>> 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 <http://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
Two thoughts:
- We should follow the spec and assume that definitions.xml are global in an SCA domain. Using the contribution resolve mechanism would contribute to pollute app artifacts (contributions) with Policy related declarations (as your app contributions would have to declare imports for the policies).
- This issue is just another manifestation of a bigger issue with the Contribution service which runs the resolve phase too early, per contribution, before all contributions are read. Fixing that will fix the Policy issue and will allow us to remove the workarounds in the current Policy processing code, which - although I didn't completely understand that code - seems to change the Intent's unresolved flag when it shouldn't.
--
Jean-Sebastien
Does anyone know if something changed recently to cause this problem or did it exist before in the 1.2 release? It sounds like it existed before and as it seems like a non-trivial fix I wondered if we could still release 1.3 anyway and try to fix this later in a 1.3.1 release?
...ant
--
Thanks & Regards,
Ramkumar Ramalingam
So am I right in thinking that this patch does not affect release 1.3?
Simon
That looks right to me, the change was in r675018 in trunk and thats not included the 1.3 branch.
...ant
OK, agreed. (I'm just running through the samples etc. now. It looks like Raymond has applied his patch so we just about good to go I think)
Simon
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jul 28, 2008 at 7:39 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Mon, Jul 28, 2008 at 7:33 PM, Simon Laws <si...@googlemail.com>wrote:
>
>>
>>
>> On Mon, Jul 28, 2008 at 7:02 PM, Ramkumar R <ra...@gmail.com>wrote:
>>
>>> Hi Ant,
>>> I believe, this issue cropped up due to a fix provided through
>>> TUSCANY-2354, this issue did not exist before in 1.2 release as the code did
>>> not do proper validation to ensure that all the intents and policysets are
>>> resolved. TUSCANY-2354 came up with a fix as to resolve all the simple
>>> intents first and then simple policysets and then the referred policysets
>>> and so on, which i believe worked for most of the validation.
>>>
>>> Currently, I am able to resolve this issue by applying this patch....
>>> (reason: a confilict exist wsClientAuthenticationPolicy)
>>>
>>> Index:
>>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
>>> ===================================================================
>>> ---
>>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (revision
>>> 680260)
>>> +++
>>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (working
>>> copy)
>>> @@ -37,7 +37,7 @@
>>> </tuscany:wsConfigParam>
>>> </sca:policySet>
>>>
>>> - <sca:policySet name="wsClientAuthenticationPolicy"
>>> + <sca:policySet name="wsClientAuthenticationPolicy2"
>>> provides="tuscany:wsAuthentication"
>>> appliesTo="//sca:binding.ws">
>>> <tuscany:wsConfigParam>
>>> Index:
>>> src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
>>> ===================================================================
>>> ---
>>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (revision
>>> 680260)
>>> +++
>>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (working
>>> copy)
>>> @@ -41,7 +41,7 @@
>>> <reference name="helloWorldWS" />
>>> </component>
>>>
>>> - <reference name="helloWorldWS"
>>> promote="HelloWorldComponent/helloWorldWS"
>>> policySets="tuscany:wsClientAuthenticationPolicy">
>>> + <reference name="helloWorldWS"
>>> promote="HelloWorldComponent/helloWorldWS"
>>> policySets="tuscany:wsClientAuthenticationPolicy2">
>>> <interface.wsdl interface="
>>> http://helloworld-om-uri#wsdl.interface(HelloWorld<http://helloworld-om-uri/#wsdl.interface%28HelloWorld>)"
>>> />
>>> <binding.ws wsdlElement="
>>> http://helloworld-om-uri#wsdl.binding(HelloWorldSoapBinding<http://helloworld-om-uri/#wsdl.binding%28HelloWorldSoapBinding>
>>> )"
>>> uri="http://localhost:8085/myExplicitURI"/<http://localhost:8085/myExplicitURI%22/>
>>> >
>>>
>>> Can anyone try this and let me know if this works.
>>>
>>> NOTE: I also strongly believe that we need to address the issue of
>>> treating the definitions.xml as global to SCA domain, and try to resolve the
>>> policy artifacts once all the policy definitions are loaded.
>>>
>>>
>>> On 7/28/08, ant elder <an...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org> wrote:
>>>>
>>>>> Simon Laws wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>>>>> enjoyjava@gmail.com>> 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 <ma...@gmail.com>
>>>>>> *Sent:* Saturday, July 26, 2008 4:20 AM
>>>>>> *To:* dev@tuscany.apache.org <ma...@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
>>>>>>
>>>>>> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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>
>>>>>>
>>>>>> <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>
>>>>>>
>>>>>> <
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Two thoughts:
>>>>>
>>>>> - We should follow the spec and assume that definitions.xml are global
>>>>> in an SCA domain. Using the contribution resolve mechanism would contribute
>>>>> to pollute app artifacts (contributions) with Policy related declarations
>>>>> (as your app contributions would have to declare imports for the policies).
>>>>>
>>>>> - This issue is just another manifestation of a bigger issue with the
>>>>> Contribution service which runs the resolve phase too early, per
>>>>> contribution, before all contributions are read. Fixing that will fix the
>>>>> Policy issue and will allow us to remove the workarounds in the current
>>>>> Policy processing code, which - although I didn't completely understand that
>>>>> code - seems to change the Intent's unresolved flag when it shouldn't.
>>>>>
>>>>> --
>>>>> Jean-Sebastien
>>>>>
>>>>
>>>> Does anyone know if something changed recently to cause this problem or
>>>> did it exist before in the 1.2 release? It sounds like it existed before and
>>>> as it seems like a non-trivial fix I wondered if we could still release 1.3
>>>> anyway and try to fix this later in a 1.3.1 release?
>>>>
>>>> ...ant
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Ramkumar Ramalingam
>>
>>
>> So am I right in thinking that this patch does not affect release 1.3?
>>
>> Simon
>>
>
> That looks right to me, the change was in r675018 in trunk and thats not
> included the 1.3 branch.
>
> ...ant
>
>
>
OK, agreed. (I'm just running through the samples etc. now. It looks like
Raymond has applied his patch so we just about good to go I think)
Simon
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by ant elder <an...@gmail.com>.
On Mon, Jul 28, 2008 at 7:33 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Mon, Jul 28, 2008 at 7:02 PM, Ramkumar R <ra...@gmail.com> wrote:
>
>> Hi Ant,
>> I believe, this issue cropped up due to a fix provided through
>> TUSCANY-2354, this issue did not exist before in 1.2 release as the code did
>> not do proper validation to ensure that all the intents and policysets are
>> resolved. TUSCANY-2354 came up with a fix as to resolve all the simple
>> intents first and then simple policysets and then the referred policysets
>> and so on, which i believe worked for most of the validation.
>>
>> Currently, I am able to resolve this issue by applying this patch....
>> (reason: a confilict exist wsClientAuthenticationPolicy)
>>
>> Index:
>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
>> ===================================================================
>> ---
>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (revision
>> 680260)
>> +++
>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (working
>> copy)
>> @@ -37,7 +37,7 @@
>> </tuscany:wsConfigParam>
>> </sca:policySet>
>>
>> - <sca:policySet name="wsClientAuthenticationPolicy"
>> + <sca:policySet name="wsClientAuthenticationPolicy2"
>> provides="tuscany:wsAuthentication"
>> appliesTo="//sca:binding.ws">
>> <tuscany:wsConfigParam>
>> Index:
>> src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
>> ===================================================================
>> ---
>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (revision
>> 680260)
>> +++
>> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (working
>> copy)
>> @@ -41,7 +41,7 @@
>> <reference name="helloWorldWS" />
>> </component>
>>
>> - <reference name="helloWorldWS"
>> promote="HelloWorldComponent/helloWorldWS"
>> policySets="tuscany:wsClientAuthenticationPolicy">
>> + <reference name="helloWorldWS"
>> promote="HelloWorldComponent/helloWorldWS"
>> policySets="tuscany:wsClientAuthenticationPolicy2">
>> <interface.wsdl interface="
>> http://helloworld-om-uri#wsdl.interface(HelloWorld<http://helloworld-om-uri/#wsdl.interface%28HelloWorld>)"
>> />
>> <binding.ws wsdlElement="
>> http://helloworld-om-uri#wsdl.binding(HelloWorldSoapBinding<http://helloworld-om-uri/#wsdl.binding%28HelloWorldSoapBinding>
>> )"
>> uri="http://localhost:8085/myExplicitURI"/<http://localhost:8085/myExplicitURI%22/>
>> >
>>
>> Can anyone try this and let me know if this works.
>>
>> NOTE: I also strongly believe that we need to address the issue of
>> treating the definitions.xml as global to SCA domain, and try to resolve the
>> policy artifacts once all the policy definitions are loaded.
>>
>>
>> On 7/28/08, ant elder <an...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org> wrote:
>>>
>>>> Simon Laws wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>>>> enjoyjava@gmail.com>> 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 <ma...@gmail.com>
>>>>> *Sent:* Saturday, July 26, 2008 4:20 AM
>>>>> *To:* dev@tuscany.apache.org <ma...@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
>>>>>
>>>>> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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>
>>>>>
>>>>> <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>
>>>>>
>>>>> <
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>> Two thoughts:
>>>>
>>>> - We should follow the spec and assume that definitions.xml are global
>>>> in an SCA domain. Using the contribution resolve mechanism would contribute
>>>> to pollute app artifacts (contributions) with Policy related declarations
>>>> (as your app contributions would have to declare imports for the policies).
>>>>
>>>> - This issue is just another manifestation of a bigger issue with the
>>>> Contribution service which runs the resolve phase too early, per
>>>> contribution, before all contributions are read. Fixing that will fix the
>>>> Policy issue and will allow us to remove the workarounds in the current
>>>> Policy processing code, which - although I didn't completely understand that
>>>> code - seems to change the Intent's unresolved flag when it shouldn't.
>>>>
>>>> --
>>>> Jean-Sebastien
>>>>
>>>
>>> Does anyone know if something changed recently to cause this problem or
>>> did it exist before in the 1.2 release? It sounds like it existed before and
>>> as it seems like a non-trivial fix I wondered if we could still release 1.3
>>> anyway and try to fix this later in a 1.3.1 release?
>>>
>>> ...ant
>>>
>>>
>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>
> So am I right in thinking that this patch does not affect release 1.3?
>
> Simon
>
That looks right to me, the change was in r675018 in trunk and thats not
included the 1.3 branch.
...ant
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jul 28, 2008 at 7:02 PM, Ramkumar R <ra...@gmail.com> wrote:
> Hi Ant,
> I believe, this issue cropped up due to a fix provided through
> TUSCANY-2354, this issue did not exist before in 1.2 release as the code did
> not do proper validation to ensure that all the intents and policysets are
> resolved. TUSCANY-2354 came up with a fix as to resolve all the simple
> intents first and then simple policysets and then the referred policysets
> and so on, which i believe worked for most of the validation.
>
> Currently, I am able to resolve this issue by applying this patch....
> (reason: a confilict exist wsClientAuthenticationPolicy)
>
> Index:
> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
> ===================================================================
> ---
> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (revision
> 680260)
> +++
> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml (working
> copy)
> @@ -37,7 +37,7 @@
> </tuscany:wsConfigParam>
> </sca:policySet>
>
> - <sca:policySet name="wsClientAuthenticationPolicy"
> + <sca:policySet name="wsClientAuthenticationPolicy2"
> provides="tuscany:wsAuthentication"
> appliesTo="//sca:binding.ws">
> <tuscany:wsConfigParam>
> Index:
> src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
> ===================================================================
> ---
> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (revision
> 680260)
> +++
> modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite (working
> copy)
> @@ -41,7 +41,7 @@
> <reference name="helloWorldWS" />
> </component>
>
> - <reference name="helloWorldWS"
> promote="HelloWorldComponent/helloWorldWS"
> policySets="tuscany:wsClientAuthenticationPolicy">
> + <reference name="helloWorldWS"
> promote="HelloWorldComponent/helloWorldWS"
> policySets="tuscany:wsClientAuthenticationPolicy2">
> <interface.wsdl interface="
> http://helloworld-om-uri#wsdl.interface(HelloWorld<http://helloworld-om-uri/#wsdl.interface%28HelloWorld>)"
> />
> <binding.ws wsdlElement="
> http://helloworld-om-uri#wsdl.binding(HelloWorldSoapBinding<http://helloworld-om-uri/#wsdl.binding%28HelloWorldSoapBinding>
> )"
> uri="http://localhost:8085/myExplicitURI"/<http://localhost:8085/myExplicitURI%22/>
> >
>
> Can anyone try this and let me know if this works.
>
> NOTE: I also strongly believe that we need to address the issue of treating
> the definitions.xml as global to SCA domain, and try to resolve the policy
> artifacts once all the policy definitions are loaded.
>
>
> On 7/28/08, ant elder <an...@gmail.com> wrote:
>>
>>
>>
>> On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> wrote:
>>
>>> Simon Laws wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>>> enjoyjava@gmail.com>> 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 <ma...@gmail.com>
>>>> *Sent:* Saturday, July 26, 2008 4:20 AM
>>>> *To:* dev@tuscany.apache.org <ma...@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
>>>>
>>>> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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>
>>>>
>>>> <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>
>>>>
>>>> <
>>>> 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
>>>>
>>>>
>>>>
>>>
>>> Two thoughts:
>>>
>>> - We should follow the spec and assume that definitions.xml are global in
>>> an SCA domain. Using the contribution resolve mechanism would contribute to
>>> pollute app artifacts (contributions) with Policy related declarations (as
>>> your app contributions would have to declare imports for the policies).
>>>
>>> - This issue is just another manifestation of a bigger issue with the
>>> Contribution service which runs the resolve phase too early, per
>>> contribution, before all contributions are read. Fixing that will fix the
>>> Policy issue and will allow us to remove the workarounds in the current
>>> Policy processing code, which - although I didn't completely understand that
>>> code - seems to change the Intent's unresolved flag when it shouldn't.
>>>
>>> --
>>> Jean-Sebastien
>>>
>>
>> Does anyone know if something changed recently to cause this problem or
>> did it exist before in the 1.2 release? It sounds like it existed before and
>> as it seems like a non-trivial fix I wondered if we could still release 1.3
>> anyway and try to fix this later in a 1.3.1 release?
>>
>> ...ant
>>
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
So am I right in thinking that this patch does not affect release 1.3?
Simon
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Ramkumar R <ra...@gmail.com>.
Hi Ant,
I believe, this issue cropped up due to a fix provided through TUSCANY-2354,
this issue did not exist before in 1.2 release as the code did not do proper
validation to ensure that all the intents and policysets are resolved.
TUSCANY-2354 came up with a fix as to resolve all the simple intents first
and then simple policysets and then the referred policysets and so on, which
i believe worked for most of the validation.
Currently, I am able to resolve this issue by applying this patch....
(reason: a confilict exist wsClientAuthenticationPolicy)
Index:
modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
===================================================================
---
modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
(revision
680260)
+++
modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/definitions.xml
(working
copy)
@@ -37,7 +37,7 @@
</tuscany:wsConfigParam>
</sca:policySet>
- <sca:policySet name="wsClientAuthenticationPolicy"
+ <sca:policySet name="wsClientAuthenticationPolicy2"
provides="tuscany:wsAuthentication"
appliesTo="//sca:binding.ws">
<tuscany:wsConfigParam>
Index:
src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
===================================================================
---
modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
(revision
680260)
+++
modules/binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/configparams/WSSecurityAuthentication.composite
(working
copy)
@@ -41,7 +41,7 @@
<reference name="helloWorldWS" />
</component>
- <reference name="helloWorldWS"
promote="HelloWorldComponent/helloWorldWS"
policySets="tuscany:wsClientAuthenticationPolicy">
+ <reference name="helloWorldWS"
promote="HelloWorldComponent/helloWorldWS"
policySets="tuscany:wsClientAuthenticationPolicy2">
<interface.wsdl interface="
http://helloworld-om-uri#wsdl.interface(HelloWorld<http://helloworld-om-uri/#wsdl.interface(HelloWorld>)"
/>
<binding.ws wsdlElement="
http://helloworld-om-uri#wsdl.binding(HelloWorldSoapBinding<http://helloworld-om-uri/#wsdl.binding(HelloWorldSoapBinding>
)"
uri="http://localhost:8085/myExplicitURI"/>
Can anyone try this and let me know if this works.
NOTE: I also strongly believe that we need to address the issue of treating
the definitions.xml as global to SCA domain, and try to resolve the policy
artifacts once all the policy definitions are loaded.
On 7/28/08, ant elder <an...@gmail.com> wrote:
>
>
>
> On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Laws wrote:
>>
>>>
>>>
>>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>>> enjoyjava@gmail.com>> 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 <ma...@gmail.com>
>>> *Sent:* Saturday, July 26, 2008 4:20 AM
>>> *To:* dev@tuscany.apache.org <ma...@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
>>>
>>> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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>
>>>
>>> <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>
>>>
>>> <
>>> 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
>>>
>>>
>>>
>>
>> Two thoughts:
>>
>> - We should follow the spec and assume that definitions.xml are global in
>> an SCA domain. Using the contribution resolve mechanism would contribute to
>> pollute app artifacts (contributions) with Policy related declarations (as
>> your app contributions would have to declare imports for the policies).
>>
>> - This issue is just another manifestation of a bigger issue with the
>> Contribution service which runs the resolve phase too early, per
>> contribution, before all contributions are read. Fixing that will fix the
>> Policy issue and will allow us to remove the workarounds in the current
>> Policy processing code, which - although I didn't completely understand that
>> code - seems to change the Intent's unresolved flag when it shouldn't.
>>
>> --
>> Jean-Sebastien
>>
>
> Does anyone know if something changed recently to cause this problem or did
> it exist before in the 1.2 release? It sounds like it existed before and as
> it seems like a non-trivial fix I wondered if we could still release 1.3
> anyway and try to fix this later in a 1.3.1 release?
>
> ...ant
>
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by ant elder <an...@gmail.com>.
On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Laws wrote:
>
>>
>>
>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com<mailto:
>> enjoyjava@gmail.com>> 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 <ma...@gmail.com>
>> *Sent:* Saturday, July 26, 2008 4:20 AM
>> *To:* dev@tuscany.apache.org <ma...@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
>> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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>
>> <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>
>> <
>> 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
>>
>>
> Two thoughts:
>
> - We should follow the spec and assume that definitions.xml are global in
> an SCA domain. Using the contribution resolve mechanism would contribute to
> pollute app artifacts (contributions) with Policy related declarations (as
> your app contributions would have to declare imports for the policies).
>
> - This issue is just another manifestation of a bigger issue with the
> Contribution service which runs the resolve phase too early, per
> contribution, before all contributions are read. Fixing that will fix the
> Policy issue and will allow us to remove the workarounds in the current
> Policy processing code, which - although I didn't completely understand that
> code - seems to change the Intent's unresolved flag when it shouldn't.
>
> --
> Jean-Sebastien
>
Does anyone know if something changed recently to cause this problem or did
it exist before in the 1.2 release? It sounds like it existed before and as
it seems like a non-trivial fix I wondered if we could still release 1.3
anyway and try to fix this later in a 1.3.1 release?
...ant
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
>
>
> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <enjoyjava@gmail.com
> <ma...@gmail.com>> 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 <ma...@gmail.com>
> *Sent:* Saturday, July 26, 2008 4:20 AM
> *To:* dev@tuscany.apache.org <ma...@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
> <jsdelfino@apache.org <ma...@apache.org>> 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 <http://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
>
Two thoughts:
- We should follow the spec and assume that definitions.xml are global
in an SCA domain. Using the contribution resolve mechanism would
contribute to pollute app artifacts (contributions) with Policy related
declarations (as your app contributions would have to declare imports
for the policies).
- This issue is just another manifestation of a bigger issue with the
Contribution service which runs the resolve phase too early, per
contribution, before all contributions are read. Fixing that will fix
the Policy issue and will allow us to remove the workarounds in the
current Policy processing code, which - although I didn't completely
understand that code - seems to change the Intent's unresolved flag when
it shouldn't.
--
Jean-Sebastien
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Simon Laws <si...@googlemail.com>.
On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <en...@gmail.com> 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 <an...@gmail.com>
> *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 <
> jsdelfino@apache.org> 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
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Ramkumar R <ra...@gmail.com>.
Hi Raymond,
I believe I know about this issue, I saw the same issue some time back and
fixed it with TUSCANY-2354. As you can see from the patch file, to fix the
issue i removed the existing intent definitions
<sca:policySet name="wsClientAuthenticationPolicy"
provides="tuscany:wsAuthentication"
appliesTo="//sca:binding.ws">
from
binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/mixed/definitions.xml
and from
binding-ws-axis2/src/test/resources/org/apache/tuscany/sca/binding/ws/axis2/itests/policy/wspolicy/definitions.xml.
Not sure, why we see this again. Let me have a look at it, and post my
findings soon. Thanks.
On Sat, Jul 26, 2008 at 11:57 PM, Raymond Feng <en...@gmail.com> 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 <an...@gmail.com>
> *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 <
> jsdelfino@apache.org> 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
>
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Raymond Feng <en...@gmail.com>.
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
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 <js...@apache.org> 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
tion not found for PolicySet {http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationPolicy
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
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by ant elder <an...@gmail.com>.
On Sat, Jul 26, 2008 at 2:38 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> 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
tion not found for PolicySet {
http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationPolicy
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
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
Re: Policy error building binding-ws-axis2, was: Error building binding-ws-axis2
Posted by Raymond Feng <en...@gmail.com>.
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
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@apache.org>
Sent: Friday, July 25, 2008 4:39 PM
To: <de...@tuscany.apache.org>
Subject: Policy error building binding-ws-axis2, was: Error building
binding-ws-axis2
> Raymond Feng wrote:
>> Can you try this patch?
>
> ...
> Sorry, it didn't fix it. I'm not too surprised as the error below says the
> problem is a "provided" intent cannot be found (while your patch was
> trying to "apply" an intent).
>
> However I'm just guessing as I'm a little confused by the error message
> and the policy definitions in the failing test case.
>
>>> org.osoa.sca.ServiceRuntimeException: Provided Intent -
>>> {http://tuscany.apache.org/xmlns/sca/1.0}wsAuthentication not found for
>>> PolicySet
>>> {http://tuscany.apache.org/xmlns/sca/1.0}wsClientAuthenticationIntegrityPolicy
>
> --
> Jean-Sebastien