在SOAP响应中注入额外的xmlns可能是什么？

Question

我继承了一个Web服务，在我们不得不升级运行时环境（从JBOSS/JRE6到Tomcat7/JRE7）之前，该服务一直运行良好。除了pom.xml之外，没有任何代码更改！

事实上，它仍然工作得很好，除了许多现有的客户机不再能够处理响应，因为现在在(响应的)一个元素中出现了一个额外的名称空间属性。

也就是说，以前（在迁移之前）该元素（在 SOAP 响应中）曾经是：

<OurResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
             xsi:noNamespaceSchemaLocation="OurResponse.xsdXMLSchema-instance" 
             ourresponseVersion="M1m2v03" xmlns="">

现在是：

<v01:OurResponse acknowledgementVersion="M1m2v03" 
     xmlns:v01="http://webservice.ourdomain.com/projone/modtwo/M1m2v03">

由于不涉及代码更改，我对SOAP响应中的这个(微小但关键的)更改感到困惑。

特别是，我试图理解:

1. 生成系统的哪个部分更改了此命名空间属性？
2. 如何将其恢复到以前的行为？
3. 为什么客户会在这么小的变化上中断？（即响应的内容是相同的！

我在pom中能够发现的唯一相关变化.xml是：

> < li>

添加以下依赖关系:

<dependency>
    <groupId>org.bouncycastle</groupId>
    <artifactId>bcprov-jdk16</artifactId>
    <version>1.46</version>
</dependency>
<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>2.7.4</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-web</artifactId>
    <version>3.0.7.RELEASE</version>
    <exclusions>
        <exclusion>
            <groupId>net.sf.ehcache</groupId>
            <artifactId>ehcache</artifactId>
        </exclusion>
    </exclusions>
</dependency>

将< code > cxf-rt-frontend-jaxws 依赖项从版本2.2.7更新到版本2.7.7。

将 cxf-rt-transports-http 依赖项从版本 2.2.7 更新到 2.7.7。

将< code>cxf-rt-ws-security依赖项从版本2.2.7更新到版本2.7.7。

添加以下依赖项：

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-core</artifactId>
    <version>2.7.7</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-databinding-aegis</artifactId>
    <version>2.7.7</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-management</artifactId>
    <version>2.7.7</version>
</dependency>

同样，我假设所涉及的框架之一（CXF？Spring？在内部处理这个问题。如果这个假设是正确的，那么：

1. 生成系统的哪个部分更改了此命名空间属性？
2. 如何将其恢复到以前的行为？
3. 为什么客户会在这么小的变化上中断？（即响应的内容是相同的！

更新 1：罪魁祸首原来是 org.apache.cxf 软件包版本从 2.2.7 更改为 2.7.7。

看起来更新并不总是更好...除非有办法以编程方式强制去除命名空间前缀的旧行为？

更新2：在Tomcat7/JRE7上使用CXF 2.2.7的副作用是在发送单个SOAP消息后杀死Tomcat服务器（似乎与SSL有关）。

事实上，像Tomcat这样的古老服务器可能会因单个流氓. war包而死亡，这一事实非常令人不安，但由于我无法修复Tomcat，而且我还没有找到解决隐式命名空间前缀问题的编程方法，我尝试了各种稳定的CXF版本，这些版本将在不杀死Tomcat的情况下表现出遗留行为。

我尝试了2.7.1和2.6.10版本，但最终只有2.5.9有效。

我希望这可以帮助那些偶然发现类似问题的人。

Answer 1

由于xmlns属性的使用发生变化，不允许一致的XML实现消亡。使用前缀或不使用前缀来表示相同的数据模型是一样的。如果客户端失败，则需要修复客户端。如果您的客户机对名称空间前缀的使用而不是实际数据模型非常敏感，那么CXF不一定是一个好的选择。

很可能 CXF 升级到了最新版本的 JAX-B，并且它改变了对命名空间前缀的看法。

详细说明一下:Apache CXF被设计成专注于符合标准的web服务。Apache Axis传统上填补了不太符合标准的web服务的空间，这很好。所以没有，CXF开发社区从来没有担心过‘前缀稳定性’。如果XML在形式上是正确的，CXF测试是令人满意的。

出于这一点以及许多其他原因，CXF将JAX-B web服务的XML生成委托给官方JAX-B参考实现。CXF的新版本吸收了JAX-B的新版本。JAX-B会不时进行更改，从而重新排列名称空间前缀。

CXF 中的 XML 生成是可插拔的，因此，如果您想使用较旧的 JAX-B 或自行开发，则可以。如果您愿意，您可以提供一个“提供商”并自己完成整个工作。

CXF中有一个选项可以将一个对象传递到JAX-B中，该选项决定哪个名称空间使用哪个前缀，但是我不认为它可以用来强制默认一个特定的名称空间。通过一个提供者和一个精心配置的对JAX-B API的调用，您也许能够得到您想要的东西。

CXF用户邮件列表存档有数百封邮件，这些邮件来自和来自使用名称空间前缀向上游游动的用户。

(至于tomcat死了，嗯，那是另一个问题了。)