[
https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682646#action_12682646
]
Scott Kurz commented on TUSCANY-2906:
-------------------------------------
Hi, I opened the JIRA to say that the location/schemaLocation should be treated
as a suggestion, and that we should not give up because these locations are
incorrect or invalid. I mentioned how the BP says that WSDL location should
be just a suggestion.
Without consulting the specs, a reasonable behavior to me would be that we
should look within the contribution, but not outside (via a contribution
import) in the case where the location/schemaLocation is specified but is
incorrect/invalid.
I just took a look at the OSOA Assembly spec, and in Sec 1.10.5, it says that
an SCA runtime should not attempt to use SCA artifact resolution (contribution
import/export) after artifact-specific-resolution has failed.
That seems to validate my view about what should happen.
---- (branching off a bit into further discussion) ----
The only thing which bothers me here is that this spec statement seems maybe
ignorant of the possibility that, in an SCA-aware runtime, I might define that
the artifact-specific mechanism for resolving location/schemaLocation involves
following the SCA contribution import. Not sure if it matters for resolving
this JIRA, but maybe interesting to think about.
On the surface it seems to say that if I have some WSDLs doing xsd:import with
@schemaLocation, and I zip up the XSDs into a separate contribution, and use
contribution import/export... then I have to go remove the @schemaLocation
attrs from the WSDL... which seems overly restrictive.
> 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.
