On Sat, Jul 25, 2009 at 8:31 AM, Andreas Veithen<andreas.veit...@gmail.com> wrote: > This means that the XSD file is also in the classpath of the Axis2 web app.
I've checked and double checked, there is no other schema file on the classpath. I've gathered up more data about the issue: So, as I mentioned in the original email, I service S4 uses wsdl from S4.wsdl, which imports schema from S4.xsd, which imports schema from enterprise-common.xsd. The location of service's wsdl is <http://localhost/axis2/services/S4?wsdl>. When Axis2 service 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, how does it locate the schema? From what I can tell, it simply goes through all installed .aars looking for one that has the file. 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. Dmitry
