[
https://issues.apache.org/jira/browse/TUSCANY-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707320#action_12707320
]
Mike Edwards commented on TUSCANY-3012:
---------------------------------------
My proposed design change to fix this problem in the handling of imports and
exports between contributions is to create an extra step in the resolution of a
Contribution. The design introduces one extra phase into the process for
Contributions, called Pre-Resolve, which must take place before the Resolve
phase. All Contributions must go through the Pre-Resolve phase before any of
them go through the Resolve phase.
In the Pre-resolve phase, the Contribution ModelResolver is set up for the
contribution and the Exports and the Imports of the contribution are resolved.
This pre-resolve step effectively just gives ModelResolvers to each of the
Imports and Exports, so that they are properly prepared to handle a resolve
request for some specific artifact arising from the resolve phase of some
(other) Contribution.
Once the pre-resolve phase is complete for all Contributions, then the existing
contributionDependencyBuilder processing can take place which cross-links the
imports of contributions to the exports of other contributions, followed by the
resolve phase for all Contributions.
Now, during the resolve phase of Contribution A, if an artifact is found to be
handled via an <import/>, the Import object delegates to an Export object of
some other Contribution B - and even if Contribution B has not yet been
resolved, the Export object has the resolver in hand with which to resolve the
requested Artifact within B.
Testcases for this functionality are the "ASM_120xx_TestCase" testcases from
the OASIS SCA Assembly test suite.
To implement this updated design, the following are created or modified:
o ExtendedArtifactProcessor - interface extends ArtifactProcessor to add a
preResolve method
o ExtendedURLArtifactProcessor - extended version of URLArtifactProcessor with
the preResolve method
o DefaultURLArtifactProcessorExtensionPoint - the inner class
LazyURLArtifactProcessor modified to implement ExtendedURLArtifactProcessor
rather than URLArtifactProcessor, so that it has a preResolve method
- the preResolve method only relays on to the preResolve method of processors
that in turn implement the ExtendedURLArtifactProcessor interface - it is
ignored for processors that only implement URLArtifactProcessor
o ContributionContentProcessor - modified to implement
ExtendedURLArtifactProcessor and has an implementation of preResolve which sets
up the ModelResolver and resolves the Imports and Exports of the Contribution
o NodeImpl - added the preResolve phase into its processing of Contributions,
just prior to the dependency resolution step
> Problems in Resolving Artifacts via Imports/Exports between Multiple
> Contributions
> ----------------------------------------------------------------------------------
>
> Key: TUSCANY-3012
> URL: https://issues.apache.org/jira/browse/TUSCANY-3012
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Core Runtime
> Affects Versions: Java-SCA-2.0
> Reporter: Mike Edwards
> Assignee: Mike Edwards
> Priority: Minor
> Fix For: Java-SCA-2.0
>
>
> The OASIS SCA Assembly tests which deal with Contributions and <import/> and
> <export/> statements in sca-contribution.xml files revealed problems in the
> way that artifact resolution is handled within Tuscany.
> When using more than 2 contributions, with imports and exports taking place
> between 3 or more contributions, exceptions can occur where resolving an
> artifact in contribution A follows an import to an export in contribution B.
> It can be that contribution B has not yet been resolved - and as a result the
> export class in B is not initialized for resolving the incoming resolve
> request from the export in A.
> The current code attempts to deal with this by ordering the resolution of the
> contributions. However, there are no clear criteria for the ordering,
> especially if different kinds of artifacts (eg composites, Java classes) are
> being imported from multiple locations and are resolved to different
> locations. As a result, the code is in practice unable to derive a
> resolution order that will work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
