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生成客戶端的代碼改造一下，不過，在改造前，還是先去下一個最新版本，看看有沒有解決。

不過，用到這，也覺得有些如履薄冰的感覺，勸你還是慎用為妙！！

? 與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的慎用AXIS2(续)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。