On Mon, Jul 28, 2008 at 7:39 PM, ant elder <[EMAIL PROTECTED]> wrote:
> > > 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:* [email protected] <mailto:[email protected]> >>>>>> *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 > > > 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
