慎用AXIS2(续)

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生成客户端的代码改造一下，不过，在改造前，还是先去下一个最新版本，看看有没有解决。

不过，用到这，也觉得有些如履薄冰的感觉，劝你还是慎用为妙！！