AXIS的"dotnet_soapenc_bugfix"属性会自动重设的bug,将导致c++客户端调用soap接口失败

项目里开发的JIRA,使用了AXIS对外提供了soap接口。另外我们使用了gsoap开发了一个com组件,并通过它实现Excel上传问题单到JIRA服务器上。今天碰到一台服务器的这个功能居然失效了,经定位发现是com组件调用java的soap接口失败了。

 

 

通常遇到这种情况肯定会认为是JIRA出问题了,但是后来我使用了soapTest工具测试了一些SOAP接口,并写了一个JAVA CLIENT调用了下SOAP接口发现接口并没有问题。后来只能比较本地正常的JIRA服务返回数据与出问题的服务器返回数据有什么区别,这才发现是服务的wsdl定义变了

正常的wsdl是定义为:<element name="email" nillable="true" type="xsd:string"/>

而出问题的wsdl定义为<element name="email" nillable="true" type="xsoapenc:string"/>

 

即里面的所有的xsd:string都莫名其妙的变成了xsoapenc:string

 

 

经过查找了相关资料:http://www.thatsjava.com/java-enterprise/4866

                              http://issues.apache.org/jira/browse/AXIS-1879

                              http://issues.apache.org/jira/browse/AXIS-1976

 

这才发现原来AXIS存在一个"dotnet_soapenc_bugfix"属性会自动重设的bug。而一旦发生这个bug后,wsdl定义的xsd:string都会变成了xsoapenc:string,而xsd与xsoapenc两种声明方式在个大部分的客户端语言联合调用时都没有问题,比如JAVA,.NET,PHP等,但是却对c++的影响很大。而我们写的com组件是通过gsoap调用wsdl后生成的文件编译而成的,所以一旦wsdl的定义都发生了变化,自然调用接口失败。

 

 

 

目前这个bug产生的频率还不知道有多高,只能先观察一段时间后再看是否修改了。

 

 

或许只能像网上说的那样,即在每个方法钱都调用

if ( !TypeMappingImpl.dotnet_soapenc_bugfix ) {

TypeMappingImpl.dotnet_soapenc_bugfix = true;

}

 

 

你可能感兴趣的:(java,C++,String,服务器,SOAP,email)