[
https://issues.apache.org/jira/browse/AXIS2-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157217#comment-13157217
]
Warren Janssens commented on AXIS2-4451:
----------------------------------------
I'm having the exact same problem -- only the first level of xsd files is
having the schemaLocation rewritten. Having multiple xsd files is a perfectly
legitimate use case so I'm not sure I'm not sure why this is marked as invalid.
What other strategies are there for serving large hierarchies of xsd files?
> Incorrect resolution of imported schema URLs
> --------------------------------------------
>
> Key: AXIS2-4451
> URL: https://issues.apache.org/jira/browse/AXIS2-4451
> Project: Axis2
> Issue Type: Bug
> Components: wsdl
> Affects Versions: 1.4.1
> Reporter: dmitry beransky
> Assignee: Senaka Fernando
> Priority: Critical
> Fix For: 1.6.0
>
>
> [see the original email thread here:
> http://www.nabble.com/schema-location-resolution-td24648927.html]
> I have several services deployed under Axis2: S1, S1, S3. Each service
> packages it's own but identical to others copy of enterprise-common.xsd that
> gets imported from each service's specific schema file: [S1.wsdl <-- S1.xsd
> <-- enterprise-common.xsd; S3.wsdl <-- S3.xsd <-- enterprise.common.xsd].
> Let's say I next deploy a new service S4 which also has a copy of
> enterprise-common.xsd, but this copy is different from those included with
> other services (it has new element and type definitions).
> The location of S4's wsdl is <http://localhost/axis2/services/S4?wsdl>.
> When Axis2 serves the WSDL document, it rewrites schemaLocation to be
> 'schemaLocation="S4?xsd=S4.xsd"'. So, S4.xsd's absolute URL becomes
> <http://location/axis2/services/S4?xsd=S4.xsd>.
> enterprise-common.xsd location inside of S4.xsd is defined as
> 'schemaLocation="enterprise-common.xsd"'. When Axis2 returns S4.xsd
> it doesn't rewrite schema's location like it does with the wsdl document, so
> enterprise-common.xsd's absolute URL becomes
> <http://localhost/axis2/services/enterprise-common.xsd>.
> When Axis2 recieves a request for
> <http://localhost/axis2/services/enterprise-common.xsd>, which now doesn't
> have a service binding in the URL, as far as I can tell, it simply goes
> through all installed .aars looking for one that has the file. It finds it
> in the first service installed, say for example, S1. Unfortunately, S1 has
> the old version of enterprise-common.xsd that will against service S4.
> Also, consider these three URLs:
> 1. http://localhost/axis2/services/enterprise-common.xsd
> 2. http://localhost/axis2/services/S4/enterprise-common.xsd
> 3. http://localhost/axis2/services/S4?xsd=enterprise-common.xsd
> Only #3 returns the schema that is defined inside of S4.aar (the newest
> version). #1 & #2 return an older version of enterprise-common.xsd that
> sits in other .aars. If I undeploy S1, S2, and S3 .aars, then #1 & #2 return
> the latest version from S4.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
