the problem is that there is not much we can do in cxf, as the relevant code is not in cxf but in wsdl4j (more specifically, in its WSDLReaderImpl), which explicitly ignores those import statements without the schemaLocation attribute.
if this is the wrong behavior, we need to have it fixed there in wsdl4j. regards, aki 2013/9/27 Menelaos Perdikeas <mperdik...@gmail.com>: > The thing is that I am not convinced that one should have to use the > `schemaLocation` attribute to override the location of a schema to be > fetched using a catalog. At least in the JAX-WS `wsimport` tool that ships > with standard Oracle Java 7, one is able to provide alternative locations > for schemas that are simply referenced with an <import> element, without > `schemaLocation` attributes. So I am giving the same catalog to both > `wsimport` and `wsdl2java` tools, and only `wsdl2java` is unable to use the > correct entry in the catalog, that's why I suspect this to be a bug. I > dunno perhaps I should file a bug report. > > > On Fri, Sep 27, 2013 at 12:59 AM, Aki Yoshida <elak...@gmail.com> wrote: > >> hi, >> sorry for my short reply earlier. >> >> the publicId identifier is an old time identifier and has a different >> usage and syntax from the URLs. >> http://en.wikipedia.org/wiki/Formal_Public_Identifier >> >> For redirecting URLs to somewhere else, you can use system or >> rewriteSystem entries. >> So, I thought my quick reply would solve your issue, assuming the >> lookup to fall back to use the namespace URL of the import when its >> schemaLocation attribute is not set. >> >> But it looks like this assumption was wrong. In other words, the >> schemaLocation must be set when the schema needs to be retrieved. >> >> In that case, I was wondering where you get the schema that omits the >> schemaLocation attribute and if it can be processed by other schema >> based tools. >> >> regards, aki >> >> 2013/9/26 Menelaos Perdikeas <mperdik...@gmail.com>: >> > Changing the catalog entry from >> > >> > <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; >> > uri="STCcoords-v1.10.xsd"/> >> > >> > to: >> > >> > <system systemId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; >> > uri="STCcoords-v1.10.xsd"/> >> > >> > still requires adding the `schemeLocation` attribute in the `<import>` >> > element otherwise the types of the imported schema are not found. >> > That is, I still need to modify the XSD schema (which only has an >> > `<import>` element without a `schemaLocation` attribute). >> > Can you elaborate a bit more on public versus system entries? I am not >> sure >> > I get all the nuances. >> > >> > >> > On Thu, Sep 26, 2013 at 5:42 PM, Aki Yoshida <elak...@gmail.com> wrote: >> > >> >> that's not a public id. >> >> can you use the system entry instead? >> >> >> >> >> >> 2013/9/26 Menelaos Perdikeas <mperdik...@gmail.com>: >> >> > I am using Apache CXF 2.7.6 `wsdl2java` and it seems that the tool >> >> ignores >> >> > or fails to find public catalog entries. In particular I have the >> >> following >> >> > `<xs:import>` in one of my XSD files: >> >> > >> >> > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10 >> "/> >> >> > >> >> > The above cannot be properly resolved with the catalog file entry: >> >> > >> >> > <public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10"; >> >> > uri="STCcoords-v1.10.xsd"/> >> >> > >> >> > If I change the `<xs:import>` by adding a `schemaLocation` attribute, >> >> i.e. >> >> > change it to: >> >> > >> >> > <xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10 >> " >> >> > schemaLocation="http://www.ivoa.net/xml/STC/STCcoords/v1.10/> >> >> > >> >> > It resolves files, but my understanding is that this shouldn't have >> been >> >> > necessary as I don't want to have to edit the XSD I am provided with. >> >> > >> >> > The behavior is the same whether OASIS XML format or TR9401 format is >> >> used. >> >> > Kind Regards, >> >> > Menelaus. >> >> >> > > > > -- > at Thy word I will let down the net.
