Hi Benson, first of all, thanks for your fast reply.
Based on your questions, i checked some stuff, where i thought YOU could base your next answer on. So i checked the CXF versions of Service and Client, and i found out, that the client was running v2.1.6 and the service was running 2.1.4. What i did NOW is, set both versions to 2.1.6 and take out our solution from the code. The strange thing is now, that in one case it works, but in an other case it does NOT. So i actually have two different "Beans" and two different result JSP's. In the one it works fine now, but in the other it does NOT. Another issue is, that i only develop a "test-service", because the REAL service is being developped in C by another company. So right now i only made changes the test-service (2.1.6 instead of 2.1.4). But actually it should run with EVERY kind of service (even one with no CXF). That's actually the main plus of SOAP :-D I am in big trouble how to best formulate my problem, but i hope you could get it. I will once again the explain the problem that came up now, when setting 2.1.4 to 2.1.6 on service side: The Back-End is written in C. I have no impact on it. I only developped a "test-service". The Front-End is using CXF in version 2.1.6 with MTOM. It renders many pages, and RIGHT NOW, there is NO encoding problem at a Search-Result HTML [values come from Back-End], BUT there is a encoding problem at an Overview-HTML [values also come from Back-End]. Isn't this weird? Nevertheless i can answer you questions: 1) The client package of CXF is using 2.1.6 (as well as my Service now, BUT the final service won't even use CXF because it's written in C). 2) Front-End is JSP (2.0, Servlet 2.4) in combination with JSF (MyFaces 1.1.7) and the Tomahawk Extension (1.1.9), as well as Tiles (2.0.5). 3) Yes, the MTOM contents are correctly transported and coded, so that e.g. i can open and read a transported PDF without a problem. BUT simple String values are mishandled so that chars are wrongly displayed in the end, as well es during the CXF internal steps. 4) The Client is CXF, my Service is also CXF (with same versions now). When logging the SOAP Messages, the INBOUND as well as the OUTBOUND message "ENCODING Flag" is set to UTF-8 - (but in console everything is displayed in "correctly" latin, if this makes a matter). Best, Daniel -----Ursprüngliche Nachricht----- Von: Benson Margulies [mailto:[email protected]] Gesendet: Freitag, 30. Oktober 2009 11:30 An: [email protected] Betreff: Re: CXF Encoding Problem Details please. 1) What version of CXF? 2) What frontend and data binding? 3) I read you to be saying that Strings are mishandled in the actual java object fields, not in the MTOM attachment content, but please confirm. 4) What is the client? The most straightforward explanation here is that the client is sending ISO-8859-1 but CXF is interpreting it as UTF-8. Is the client CXF, or some other package? On Fri, Oct 30, 2009 at 5:38 AM, Daniel Weidele <[email protected]> wrote: > Hi @, > > > > i am currently developping a Web Application Front-End, which ist > communcating with a Web-Service Back-End. For SOAP Handling we decided to > use CXF (with MTOM!). The Front-End Rendering etc. is being done with JSP / > JSF (MyFaces Implementation). > > > > Now everything works fine and performs quite well, but we have one VERY > ENORMOUS NECK-BREAKING KILLER TROUBLE BUG, which is: > ENCODING/DECODING...[only the "special german chars" like "ä", "ö", "ü", > "ß", etc.] > > > > I already took a look into the low-level SOAP Message: Encoding is always > specified there as UTF-8, for IN-BOUND as well as the OUT-BOUND Messages. > > I did this using the cxf config xml telling the service to log the SOAP > messages to the console. So as i said i have "UTF-8" in the SOAPs - and in > the console, the chars are correctly written. > > > > Now the BUT: > > As soon as on the Front-End Side, CXF has parsed the SOAP into an "Object" > (i found this code-line in the internals of CXF), the chars are BADLY > decoded, so that i see bad characters in the Debug-Variable view. > > So even after casting the "Object" into the real "ServiceResponseObject" > and all other steps inside CXF, the String stays wrong, so that finally i > also have the badly coded String in my Front-End level. > > > > It looks like the String is being double UTF-8 encoded and afterwards only > once decoded to Latin, because out of "für" i am getting "für" as the > decoded result String. > > The other possibility would be once encoded to UTF-8, and never really > decoded. > > > > I actually have no idea where this problem might internally come from. > Maybe it has something to do with the MTOM extension? > > > > Our current solution ist just decoding the String once again after > receiving it from CXF. But of course, this is not a solution with great > glamour... > > > > So my question to you would be: > > Does anyone have any ideas what WE might have done wrong, or if there > exists a patch (if the problem is really inside CXF) or if there exists a > better solution than we have? > > > > Thanks a lot! > > Daniel > >
