[
https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713481#action_12713481
]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Hi Sean,
We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
Artifacts) in the month of March under this thread
http://www.mail-archive.com/[email protected]/msg05956.html
What we agreed on as a process to follow for the non-SCA mechanism is.....
1. get artifact location from import/include
2. if there is a location then do artifact specific resolution
3. retrieve the artifact using the location provided
4. if no artifact found look in the current contribution for an
artifact providing the appropriate namespace
5. if not found report an error
6. else do sca specific resolution
7. use the sca artifact resolution mechanism to find an artifact
providing the appropriate namespace
8. if not found report an error
So going by this process, if the artifact specified in the location attribute
is not found an error is reported either in Step 5 or 8.
Now, the question is that, do you expect that the artifacts (WSDL/XSD) to get
resolved even if the artifact specified in the location
attribute is not found anywhere after following the above process?
> 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, wsdl_cont.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.
