[
https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683002#action_12683002
]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Hi Scott,
Thanks for elaborating on this. I understand the point here.... yes as you said
currently Tuscany tries to use SCA artifact resolution (contribution
import/export)
after artifact-specific-resolution has failed.
Also from the specs I see this comments.... saying use of non-sca mechanism is
discouraged.
3060 SCA permits the use of these mechanisms. Where present, these mechanisms
take precedence
3061 over the SCA mechanisms. However, use of these mechanisms is discouraged
because tying
3062 assemblies to addresses in this way makes the assemblies less flexible and
prone to errors when
3063 changes are made to the overall SCA Domain.
Also, I see a valid use case as you have pointed out, to use the sca artifact
resolution mechanism when the XSD's are zipped into a separate contribution.
I would like to take this issue up with the community, and lets see what best
can be done here.
> WSDL/XSD imports should use location/schemaLocation as hints and not fail due
> to locations that don't map to actual locations
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2906
> URL: https://issues.apache.org/jira/browse/TUSCANY-2906
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Data Binding Runtime
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: 2906.recreate.jar
>
>
> My test app uses wsdl import and xsd import with @location and
> @schemaLocation, respectively, specifying values that don't actually
> correspond to relative locations within my contribution JAR. (The motive
> might be that in moving from my test env to my deploy env i've shuffled the
> relative paths around for some reason).
> When reading BasicProfile 1.1, section 4.2.4, I take that to mean that our
> runtime should be able to handle an "incorrect" @location (though 4.2.3 says
> it shouldn't be empty). Instead we blow up.
> In reading the XSD spec quickly I think the same should apply to
> @schemaLocation on XSD import, though I don't see that BP says anything about
> this. I did test to confirm that if @schemaLocation is simply left blank
> then we have no problem finding the XSD within the contribution... it's just
> a problem if it's set to a value that doesn't correspond to anything in the
> JAR.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
