Daniel, I suspect that your problem is in your JSP pages. Does the problematic data come from HTML form posts? Are you sure that the Content-Type on the html page with the form says 'charset=utf-8'?
Are you using the client proxy directly from JSP, or is there an intervening bean? I ask because I think you need some logging. Presumably, you've got JSP code that takes a string value from the form posting and pushes it into the 'set' function of a bean, unless it's a top-level parameter of a web method. I think you need to dump out that value and see if it's already wrong. I'm theorizing that the process of converting the HTTP-posted form data to the Java string in the JSP class has used the wrong encoding. --benson On Fri, Oct 30, 2009 at 7:07 AM, Daniel Weidele <[email protected]> wrote: > 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 > > > > >
