WS-Security Chinese problem solvingAfter learning about the next generation of JAXP, I have a basic understanding of how axis2 processes soap messages. After tracking code debugging, the problem is found mainly in the axis2util class of the Rampart module of axis2. the two methods include getdocumentfromsoapenvelope (soapenvelope ENV, Boolean usedoom) and lift (soapenvelope ENV, Boolean usedoom ). When WS-Security and none are different, the input parameters usedoom are true and false, resulting in two different parsing procedures. When usedoom is true, axis2 uses the soapenvelope object and the streaming parser of axis2 to parse and construct the DOM document. When usedoom is false, first read the soapenvelope object into the byte array stream, then generate an instance based on The Stax factory, construct the staxsoapmodelbuilder, and then return the DOM document object obtained through staxsoapmodelbuilder. Check the caller's input parameters. In fact, the policy is determined by msgcontext parameter configuration. Therefore, you only need to add a parameter to the axis2.xml configuration and set usedoom to true. Or configure the handle or phase parameter in inflow and outflow. It takes so long to modify a configuration. If we look at the results, it would be a waste of time to spend two days, but if we look at the process, so what we learned in the past two days is a comparison value. Since the next day is Sunday, the problem will not be further investigated after it is solved. However, during the morning run on Sunday, I asked myself three questions: first, why is there a problem with the Stax obtained by the system, then, if I use sun's JAXP implementation to replace whether it can solve this problem without configuring usedoom. What are the differences between the usedoom processing modes.
Further study of the problemI remember the three questions raised on Sunday morning when I went to work on Monday, so I analyzed them carefully. The first is to replace Sun's JAXP. This implementation is included in Sun's jwsdp. After the replacement, it is forced to be specified in the JRE configuration file. An exception occurs, it seems that direct use is not enough, and some parameters need to be configured, especially for namingspace parsing. At the same time, it does not take more time to study. Then, I think about the experiment I did when I located the problem. I tried to encode Chinese first with base64, and then the server receives it and then returns it. The client then decodes it with base64, no problem. Sometimes there are letters and numbers before and after a Chinese character, which can also be processed normally. At the same time, you can see the content in the SOAP message during the code tracking process. The content is garbled. This gave me some inspiration. For example, if I input the parameter "文", an error always occurs. If I input the parameter" 文”", there is no problem. I looked at the variables in the memory and found that, in the past, the tag closure in the SOAP message was damaged when it was the "Beginning of the Article". If it was the "en Wen", although it was garbled, it did not destroy the tag closure. Let's take a closer look at the two flows mentioned last time. In fact, apart from the difference in parser, the processing of soapenvelope is also different. usedoom is used to directly return the analyzed DOM object, no additional processing is required, but the soap parser and two interface implementation classes with Stax cursor configured are generated based on envelope. Without usedoom, soapenvelope is completely serialized and parsed and processed through the external Stax, but the problem lies in the serialization process from the object to the byte stream, by default, the UTF-8 encoding method specified by soap is used. Therefore, some Chinese content in this process damages the legality of the XML tag of the SOAP message package, cause an error in external parser analysis. If you encode both the incoming and outgoing Chinese characters into UTF-8, there is no problem. Problem summary is in fact the root cause of the content of the Chinese character encoding when the use of Utf-8 destroys the XML closed, and I began to use usedoom exactly to circumvent this process, it will naturally pass. However, as far as the design is concerned, Rampart should agree with the method of setting usedoom to false. This is the real Stax mode and has good scalability. On the other hand, I personally think that it is best not to forcibly specify system variables or JRE in this abstract factory mechanism, which will lead to unexpected problems. Although it is a standard, there are differences in the implementation of details after all, therefore, some inexplicable XML parsing problems of some special open-source frameworks are often caused by these problems.
Some insightsThe flexible SPI (Service Provider Interface) mode is a necessary feature of the current framework design and underlying design, so that openness can develop better. Flexibility is a double-edged sword. When encountering some flexible framework design, we must first understand its principles and structure, and then verify the cause of the problem based on practice.
Abstract Factory is still applicable to scenarios, similar to JAXP and SCA Framework implementation, abstract factory and the use of jar META-INF/services to load SPI implementation is a good supplement to IOC.
