[
https://issues.apache.org/jira/browse/AXIS2-3354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752583#action_12752583
]
Mauro Molinari commented on AXIS2-3354:
---------------------------------------
Playing around I found out that in Axis2 1.5 things work in the following way.
Suppose I have MyService1 and MyService2 deployed as such:
contextpath/WEB-INF/services/MyService1/META-INF/
contextpath/WEB-INF/services/MyService2/META-INF/
and suppose both MyService1.wsdl and MyService2.wsdl import a schema called
CommonSchema.xsd placed in:
contextpath/WEB-INF/services
so, to make Axis2 internally find the schema, both MyService1 and MyService2
must import that schema in this way:
<xsd:import namespace="<CommonSchema namespace>"
schemaLocation="../../CommonSchema.xsd"/>
However, as I described above this causes an invocation to:
http://host:8080/webapp/services/MyService1?wsdl
to generate an output where the previous xsd import is modified to:
<xsd:import namespace="<CommonSchema namespace>"
schemaLocation="MyService1?xsd=../../CommonSchema.xsd"></xsd:import>
Then, as I described in my previous comments, requests to:
http://host:8080/webapp/services/MyService1?xsd=../../CommonSchema.xsd
generate a 404 because Axis2 1.5 filters out requests of schemas containing
".." in their path. This causes clients that query Axis2 for the WSDL to fail,
because they can't retrieve the schema.
However, I found out that a request like the following:
http://host:8080/webapp/services/MyService1?xsd=CommonSchema.xsd
does work in Axis2 1.5, because Axis2 can bind the name "CommonSchema.xsd" to
the correct file, even if it is not located in the same path of the WSDL (in my
case it's in contextpath/WEB-INF/services/).
Given this, I created a patch (that I'm going to attach here) that solves this
issue and does the following: when AxisServlet is invoked to generate a WSDL or
a schema (with ?wsdl or ?xsd query string parameters), schema locations are
processed so that relative paths are removed. In this way, when you call:
http://host:8080/webapp/services/MyService1?wsdl
you'll get a WSDL with the following schema import statement:
<xsd:import namespace="<CommonSchema namespace>"
schemaLocation="MyService1?xsd=CommonSchema.xsd"></xsd:import>
that is, without the leading "../../" in the schemaLocation attribute value.
Please note that it is however necessary to keep your WSDLs with the
schemaLocation attribute value with the leading "../../", otherwise Axis2 won't
be able to locate the schemas internally and won't generate the WSDL correctly
(I think that service invocations will fail too).
My only perplexity now is that I don't know what can happen if a WSDL imports
two different schemas defined in files with the same name but located in
different paths. My patch doesn't help here, but I fear that Axis2 itself could
not locate schemas properly anymore, because
org.apache.axis2.description.AxisService.printXSD(OutputStream, String) is
trying to match requests against schemas using a Map whose keys are just the
names of the files of the imported schemas, not their full paths (as defined in
schemaLocation).
> Allow for sharing XSD schemas between services
> ----------------------------------------------
>
> Key: AXIS2-3354
> URL: https://issues.apache.org/jira/browse/AXIS2-3354
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Affects Versions: 1.5, 1.3
> Reporter: Mauro Molinari
> Assignee: Deepal Jayasinghe
> Priority: Blocker
>
> Suppose I have the following structure:
> The WSDLs for MyService1 and MyService2 are in the following folders,
> respectively:
> contextpath/WEB-INF/services/MyService1/META-INF/
> contextpath/WEB-INF/services/MyService2/META-INF/
> I want them to share Common.xsd: as of now, it seems that there's no way to
> get this to work.
> If I put it here:
> contextpath/WEB-INF/services/
> and the xsd:import schemaLocation in the WSDLs points to "../../Common.xsd",
> Axis2 can find the XSD and processes the services correctly, but when it
> substitutes the link to it in the WSDLs, it generates the following links:
> MyService1?xsd=../../Common.xsd (in MyService1 WSDL)
> MyService2?xsd=../../Common.xsd (in MyService2 WSDL)
> The problem is that from an HTTP client point of view, this translates to
> path contextpath/Common.xsd: in fact, if you try to write the link:
> http://server:8080/contextpath/services/MyService1?xsd=../../Common.xsd
> a "file not found" error is given.
> Another clue is that if I try to generate a client pointing to
> http://server:8080/contextpath/services/MyService1?wsdl, WSDL2Java says that
> it cannot retrieve the schema.
> By manually typing:
> http://server:8080/contextpath/services/MyService1?xsd=../Common.xsd
> I see that the schema can actually be found; but if I replace the xsd:import
> in the original WSDL so that the schemaLocation points to "../Common.xsd",
> then Axis2 can't find it anymore, because it searches for it in
> contextpath/WEB-INF/services/MyService1/ and the generation of the WSDL fails.
> So, my request is this: add a supported way to share schemas (and maybe WSDLs
> portions) between services.
> Maybe the system should allow a default common repository where shared
> schemas and WSDLs can be placed? Or should the way in which Axis2 rewrites
> the schemaLocation link in the WSDL when imported resources are mapped to
> file outside the current folder simply fixed?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
