You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2009/03/05 23:33:56 UTC
[jira] Created: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
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
Priority: Minor
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.
Re: [jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't map
to actual locations
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Mar 27, 2009 at 9:48 AM, ant elder (JIRA)
<de...@tuscany.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689864#action_12689864 ]
>
> ant elder commented on TUSCANY-2906:
> ------------------------------------
>
> and TUSCANY-2948
>
>> 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.
>
>
Hi Ant
And the reason why you are seeing so many more problems that I am is
that I haven't taken the 2906 changes yet. I'm going to get to a stage
where I have a clean build locally before upgrading as there are other
problems that are being masked by the schema location related
problems. Am looking at the NPE in the store tutorial now.
Simon
[jira] Resolved: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ 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.
[jira] Updated: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Kurz updated TUSCANY-2906:
--------------------------------
Attachment: 2906.recreate.jar
> 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
> 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.
[jira] Reopened: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam reopened TUSCANY-2906:
------------------------------------------
Looks like the expectation for this JIRA is a bit different that what is discussed in thread
http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ 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/dev@tuscany.apache.org/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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689423#action_12689423 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Committed revision 758582 & 758583 in 1.x.
I will keep this JIRA open, until every thing is good with this patch.
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711984#action_12711984 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Hi Sean,
Will have a look at this one on Monday and post my comments on the same. Thanks.
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689864#action_12689864 ]
ant elder commented on TUSCANY-2906:
------------------------------------
and TUSCANY-2948
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689862#action_12689862 ]
ant elder commented on TUSCANY-2906:
------------------------------------
See also TUSCANY-2947
> 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.
[jira] Resolved: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam resolved TUSCANY-2906.
------------------------------------------
Resolution: Fixed
Testcase for this scenario is now committed at revision 790139 in 1.x.
> 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.
[jira] Updated: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam updated TUSCANY-2906:
-----------------------------------------
Attachment: TUSCANY-2906-Part2.patch
TUSCANY-2906-Part1.patch
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689531#action_12689531 ]
ant elder commented on TUSCANY-2906:
------------------------------------
Could this change be related to any of the test fails we have in the build related to TUSCANY-2943, 2944, 2945? (I've not looked at all so appologie sif it doesn't it just sounds like it might as its to do with imports)
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ 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.
[jira] Assigned: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ramkumar Ramalingam reassigned TUSCANY-2906:
--------------------------------------------
Assignee: Ramkumar Ramalingam
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Sean Zhou (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711751#action_12711751 ]
Sean Zhou commented on TUSCANY-2906:
------------------------------------
The fix doesn't seem to solve the problem. I have attached the contribution which I used to verify the fix.
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699752#action_12699752 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Implementation details for this JIRA is been discussed in the following mailing list:
http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
[ 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682578#action_12682578 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Hi Scott,
I tried the scenario you have attached and what I notice is that Tuscany throws ContributionResolveException in both the cases...
Case 1: improper @schemaLocation on XSD import
SEVERE: Error in contribution: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
Exception in thread "main" org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:192)
at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
at bigbank.server.BigBankServer.main(BigBankServer.java:48)
Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:381)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:77)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:452)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:988)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:89)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:203)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:57)
at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:596)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:423)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:195)
at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:517)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:188)
... 2 more
Case 2: improper @location on WSDL import
SEVERE: Error in contribution: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
Exception in thread "main" org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:192)
at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
at bigbank.server.BigBankServer.main(BigBankServer.java:48)
Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:381)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:77)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:452)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:988)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:89)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:203)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:57)
at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:596)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:423)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:195)
at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:517)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:188)
... 2 more
Which I think is the expected results, not sure if you are mean to point out some else out of this issue.
I like to get more details on the issue raised, as what is the expectations? Please clarify.
> 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.
[jira] Updated: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Sean Zhou (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sean Zhou updated TUSCANY-2906:
-------------------------------
Attachment: wsdl_cont.jar
> 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.
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
Posted by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741290#action_12741290 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Problem: This issue was re-opened to fix the resolution of wsdl:import and xsd:import using namespace, in case where the import location is in-correct.
Action Taken: In case the location points to a incorrect path, we just use the namespace and check within the current contribution for
any appropriate files matching the target namespace and return the matching file.
Committed revisions:
Committed revision 801107, 801108, 801111 in 1.x.
Committed revision 802758 in 1.5.1.
> 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.