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
