It probably is a bug in CXF. Feel free to log it. (and a patch would be nice :-)
However, there is another issue that you need to think about: If the xsd's are to be hosted from the same "localhost" container as the service, the service may not start. For example, in tomcat, it loads and initializes all wars before starting the port listener. Thus, if we try to go back to "http://localhost"; to get the xsd, there won't be anything listening on the port and we won't be able to get the wsdl. The service won't start. Dan On Thursday 10 April 2008, [EMAIL PROTECTED] wrote: > 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(Catal >ogXMLS 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 > > ---------------------------------------------------------------- > Peter Liljenberg > TeliaSonera AB > Software Architect, TSS-IT Channel Technologies > > Cell: +46 (0)703 790 793 > e-mail: [EMAIL PROTECTED] > ----------------------------------------------------------------- -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
