http://blog.csdn.net/mudboy/archive/2006/09/08/1194535.aspx
一文中说到我使用AXIS2所遇到的一些问题,那是服务端的一些问题,但其实在自动生成客户端代码方面也有一些问题,场景如下:
1、 环境:前后端都是AXIS2,一些操作,部署或代码生成都安默认方式进行。
2、 后端发布SERVICE
3、 前端根据WSDL生成代码
4、 测试客户端,没有问题。
5、 更新服务端的一些东西(甚至只是重启服务端),注意未改变发布的接口。
6、 用上面的客户端测试,抛出异常,错误信息是“意料之外的元素***”,说白了就是解析不了返回的SOAP消息了。
7、 再生成一次代码,测试,OK。
为了查明此问题,首先当然是看前后的WSDL是不是有变化,结果发现还真有一些变化,但只是一些消息申明的顺序有变化(为什么会有这样的变化,有些莫明其妙,没有深究),应该并不影响最终的SOAP生成,只是同层次的元素可能顺序会有些变化,比如:
从:
<a>
<a1>a</a1>
<a2>a</a2>
<a3>a</a3>
<a4>a</a4>
</a>
变化成:
<a>
<a3>a</a3>
<a1>a</a1>
<a2>a</a2>
<a4>a</a4>
</a>
按常理,如果SCHEMA中不规定元素的顺序,客户端不应该因为这种变化而无法成功解析,但看看AXIS2生成的客户端代码,却有些死板,位置变了/少了/多了都不行,必须一模一样,可想而知这样的代码在生产中是没有办法使用的。
最后解决办法是自己改了相应的解析代码,并且尽可能的灵活,即使顺序有变化或是增加了新元素,也不会影响响应的解析工作。
有时间的话干脆把AXIS2生成客户端的代码改造一下,不过,在改造前,还是先去下一个最新版本,看看有没有解决。
不过,用到这,也觉得有些如履薄冰的感觉,劝你还是慎用为妙!!