[jira] Commented: (TUSCANY-3012) Problems in Resolving Artifacts via Imports/Exports between Multiple Contributions

["Mike Edwards (JIRA)" <de...@tuscany.apache.org>]

    [ 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.