Apache CXF :: wsdl2java ignoring catalog configuration for public entries

Question

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.

Answer 1

The reply I got from the Apache CXF users mailing list is that the XML Schema specification leaves this point up to the implementation and so is not considered a bug.

Thread here (the post is dated September 26th 2013, is on page 2 and I don't seem to be able to provide a link directly to that page). The relevant conclusion is here. I quote:

My thoughts on this:

1) According to the schema spec, if the schemaLocation hint isn't specified, it's up to the application to figure out how to resolve it if needed. Thus, I don't really consider this a "bug". We specifically just use the information provided and is part of the "compilation unit" (aka: wsdl).

2) Personally, I think it's pretty silly to NOT provide the schemaLocation and would STRONGLY STRONGLY recommend adding it. The only time I've ever seen it not specified is when importing schemas that are also embedded in the same wsdl (so there isn't a location).
When ever I see things like "up to the application" in specs, that, to me, is an interoperability nightmare. Just specify it.

3) That all said, the root issue would be in XmlSchema's SchemaBuilder class. If there isn't a schemaLocation, it assumes it's part of the compilation unit it's working on and continues. Doesn't try to resolve anything. If you want to pursue a patch or something, it would be around 680 of SchemaBuilder.java. But even changing that MAY require more support from CXF's side to pre-populate the namespaces it already knows to avoid it going off to the internet for them. Not really sure.

So, it is confirmed that:

• the default wsimport tool that ships with Oracle Java 7 does use a catalog to resolve an import statement even without a schemaLocation attribute.
• the Apache CXF 2.7.6 wsdl2java tool does not use a catalog to resolve an import statement without a schemaLocation attribute
• the Apache CXF community does not view this as a bug.