On Mon, Jul 28, 2008 at 7:33 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Mon, Jul 28, 2008 at 7:02 PM, Ramkumar R <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> On Mon, Jul 28, 2008 at 6:20 PM, Jean-Sebastien Delfino < >>> [EMAIL PROTECTED]> wrote: >>> >>>> Simon Laws wrote: >>>> >>>>> >>>>> >>>>> On Sat, Jul 26, 2008 at 7:27 PM, Raymond Feng <[EMAIL PROTECTED]<mailto: >>>>> [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 <mailto:[EMAIL PROTECTED]> >>>>> *Sent:* Saturday, July 26, 2008 4:20 AM >>>>> *To:* dev@tuscany.apache.org <mailto: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] <mailto:[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 <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
