Hi, I'm writing some code that will allow me to deploy webservices that has been setup as ServicePoints in Hivemind. This way I can build components (JARs) with the webservice that I want to deploy and just add them to the classpath of my WAR project and they will deployed. No need to configure everything in one xml file, distributed configuration (maybe something to commit back to CXF when I'm "done"?). It works just fine until I realize that I want to import XSD schemas in my WSDLs to allow validation of the SOAP requests. Now, I have several webservices sharing XSDs (one entity model for several services and so on) so I don't want to package the XSDs in the JAR that contains the implementation code and the WSDL for the actual service. I add an import for a external resource in my test.wsdl:
<xsd:import ..... schemaLocation="http://localhost/entities/user.xsd"; /> Generating Java code with WSDL2JAVA works fine, and I set the @Webservice annotation accordingly (wsdlLocation="schemas/service/test.wsdl), the WSDL will reside in the JAR file that is built with the service code, the XSDs are NOT, they reside on a server (in this case localhost). Now, when I deploy my WAR file containing the JAR I get an error (removing the wsdlLocation from the Webservice annotation - thus building service from SEI instead of WSDL - will work just fine, but then I lose the validation!) like this: ...XMLSchemaException: Unable to locate imported document at 'http://localhost/entities/user.xsd', relative to 'jar:file://......./warfile.war/WEB-INF/lib/test.jar!/schemas/services/test. wsdl'. at org.apache.cxf.catalog.CatalogXMLSchemaURIResolver.resolveEntity(CatalogXMLS chemaURIResolver.java:71). Digging down in the code we end up in the ExtendedURIResolver.resolve (line 42) that makes a call to resolve in org.apache.cxf.resource.URIResolver.resolve. This method totally ignores that my URI starts with 'http' it just assumes a JAR, CLASSPATH or FILESYSTEM path. This seems kind of silly? Any URL should be possible to resolve? If I change the baseUriStr (jar:file://....) - removing the 'jar:' when debugging I can get it to work since then I end up in the tryFileSystem method which actually can resolve a HTTP URL, I'm thinking that this should be tried if JAR resolving fails? Or maybe even before JAR resolving? What do you think? Should I file this as an JIRA issues? I feel it's a bug, easy to fix as well, and would to get it fixed in the next release of CXF. Regards, Peter
smime.p7s
Description: S/MIME cryptographic signature
