Would you like me to file a bug report? I would be happy to do so but provide me coordinates as I want to make sure I file it against the right project.
On Fri, Sep 27, 2013 at 2:58 PM, Aki Yoshida <[email protected]> wrote: > 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 <[email protected]>: > > 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 <[email protected]> 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 <[email protected]>: > >> > 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 <[email protected]> > wrote: > >> > > >> >> that's not a public id. > >> >> can you use the system entry instead? > >> >> > >> >> > >> >> 2013/9/26 Menelaos Perdikeas <[email protected]>: > >> >> > 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. > -- at Thy word I will let down the net.
