[
https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramkumar Ramalingam resolved TUSCANY-2906.
------------------------------------------
Resolution: Fixed
Looks like we have meet the expectation of this JIRA as discussed in the thread.
> 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, TUSCANY-2906-Part1.patch,
> TUSCANY-2906-Part2.patch
>
>
> 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.
