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
