Xifre problems with Webshpere when intercepting soap

Source: Internet
Author: User

Baidu search keyword "Xfire intercept soap", you can see a lot of the same way to achieve this function (I found the same technical problem in Baidu search a lot of identical posts, really feel this is not a good phenomenon, at least reprint should also indicate the source AH), Of course I also chose this feature, the approximate implementation of the principle can see this post: http://blog.sina.com.cn/s/blog_58844e710100gpr7.html.

The focus of this article is not on the method above, but on how to request a service when deploying to a Linux system websphere7.0 in this way, how a node like this appears in a SOAP message "<description> 's discovery [email Protected]#$%^&amp;^&amp;**%$##</description> ", the focus is the value of this node, more important is that the value of this node has" ^&amb ", Then when you take it out you will find that the content is wrong and that it is a duplicate string.

I was plagued by this problem for a whole one weeks and I was despised by my colleagues.

This problem did not appear on Tomcat, so the first thing to consider is what is different about WebSphere and the local environment, but where is it different? Where did it come from? One weeks of tossing, still no solution. So go to another system to test whether the problem also occurs, their system is the same environment as mine, the framework of the system is the same. Hostile hope they have this problem, as a result I rub, they do not have this problem. But that's a good thing, at least let me find the problem by comparing the different parts of the two systems, and maybe you can guess. This is the way to intercept soap. Our two systems are not the same, and obviously my way is causing the problem.

So download Xfire source code, step by step debugging, finally let me find this problem lies. Here is some of the code in the Invoke method in Org.codehaus.util.dom.DOMInHandler:

   

        doc = Staxutils.read (Dbf.newdocumentbuilder (), Context.getinmessage (). Getxmlstreamreader (), false);                Context.getinmessage (). SetProperty (Dom_message, doc);        Context.getinmessage (). Setxmlstreamreader (New W3cdomstreamreader (Doc.getdocumentelement ()));

The problem is that the W3cdomstreamreader obtained from the source of the input stream is assigned to the Xmlstreamreader, A Java class that was used in the conversion process might have been modified by IBM on WebSphere to cause this function to be different from the local running result, but let's not say how much problem IBM has caused by modifying Java's class library in order for WebSphere to run in a more frenzied way. But the problem you are not able to use the native JRE class library to replace the IBM class Library, or WebSphere must be reported a large pile of exceptions to protest and the dead start not up. The only way is to do something.

through the Xfire source to understand the beginning of this xmlstreamreader to obtain the way, still decided to use this way to get xmlstreamreader to replace this let me 5 days and nights of the way. Then added a class Cdominhandler inherit Xfire dominhandler and modify the forwarding method, the above code modified as follows:

             doc = Staxutils.read (Dbf.newdocumentbuilder (), Context.getinmessage (). Getxmlstreamreader (), false);    Context.getinmessage (). SetProperty (Dom_message, doc);        Domreader XmlReader = new Domreader (); Org.dom4j.Document Dom4jdoc = Xmlreader.read (DOC); StringBuffer soapstr = new StringBuffer (Dom4jdoc.asxml ()); InputStream in = new Bytearrayinputstream (soapStr.toString () . GetBytes (Context.getinmessage (). GetEncoding ())); Xmlstreamreader reader =              staxutils.createxmlstreamreader (in, Context.getinmessage (). GetEncoding (), context);             
             Context.getinmessage (). Setxmlstreamreader (reader);        Context.getinmessage (). Setxmlstreamreader (New W3cdomstreamreader (Doc.getdocumentelement ()));

Finally, the excitement of the heart made me sleepless at night, so I watched the game in Holland and Argentina, and the result ... Results...... Holland lost, whining, don't stop me, let me sleep will feel, sleepy all cry out.


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.