This means that the XSD file is also in the classpath of the Axis2 web app.
Andreas On Fri, Jul 24, 2009 at 19:44, Dmitry Beransky<dmitry.ma...@gmail.com> wrote: > Hi, > > I have several services deployed under Axis2: S1, S1, S3. Each > service packages it's own copy of enterprise-common.xsd. Now I need > to 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 > problem is now, that when I request the schema file like so: > http://localhost/axis2/services/S4/enterprise-common-2.0.xsd, I an > older version of the schema file included with one of the other > services gets served back. > > So the question are: 1) why isn't the schema served from the S4 > bundle?; 2) is this a bug; 3) is there anything I can do in axis2's > configuration to change this behavior? > > Because of the way the build process has historically been set up in > my company, I cannot easily version the schema file (e.g. > enterprise-common-2.1.xsd, doing so would require major changes to the > build process). > > Oh, and enterprise-common.xsd gets imported from each service's > specific schema file: [S4.wsdl <-- S4.xsd <-- enterprise.common.xsd]. > Axis2 overwrites WSDL's import statement to > schemaLocation="S4?xsd=S4.xsd", but S4.xsd's import statement never > gets overwritten to "schemaLocation=S4?xsd=enterprise-common.xsd" > (which actually works correctly) > > > > thanks > Dmitry >
