我正在使用Apache CXF 2.7.6 wsdl2java,看来该工具会忽略或无法找到公共目录条目.特别是我有以下< xs：import>在我的XSD文件之一中：

<xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10"/>

上面的目录文件条目无法正确解决以上问题：

<public publicId="http://www.ivoa.net/xml/STC/STCcoords/v1.10" uri="STCcoords-v1.10.xsd"/>

如果我更改< xs：import>通过添加schemaLocation属性,即将其更改为：

<xs:import namespace="http://www.ivoa.net/xml/STC/STCcoords/v1.10" schemaLocation="http://www.ivoa.net/xml/STC/STCcoords/v1.10/>

它可以解析文件,但是我的理解是这不是必须的,因为我不想编辑我提供的XSD.

无论使用OASIS XML格式还是TR9401格式,行为都是相同的.

解决方法:

我从Apache CXF用户邮件列表中得到的答复是XML Schema规范将这一点留给实现,因此不被视为错误.

主题here(帖子发布日期为2013年9月26日,位于第2页,我似乎无法直接提供指向该页面的链接).相关结论是here.

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.

因此,可以确认：

> Oracle Java 7附带的默认wsimport工具确实使用目录来解析导入语句,即使没有schemaLocation属性也是如此.
> Apache CXF 2.7.6 wsdl2java工具不使用目录来解析没有schemaLocation属性的导入语句
> Apache CXF社区并不将此视为错误.