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 ; [EMAIL PROTECTED]
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 <[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)" />
<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 <[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>
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
