Please send a complete dump of the soap message. That encoding disturbs me.
On Fri, Oct 30, 2009 at 8:22 AM, Daniel Weidele <[email protected]> wrote: > Alright, i once again debugged it, and found out the following: > > Soap Message have the Attribute "ENCODING" set to "ISO-8859-1" but in the > Content-Type attribute "charset" in the Payload is set to "UTF-8". > Is "Payload" MTOM specific? > > Ok this is the one aspect. The other aspect is, that the String comes > CORRECTLY back from the Service, BUT the Value has been sent WRONG tot he > service before. > > So it works like the following: > > User enters a String in a Form (HTML Encoding is UTF-8). This String is > correctly parsed into a Java Bean. Then this value is being transmitted via > CXF tot he service, where it comes out wrongly coded. > The services stores that String into a HashMap. > > Next the client wants to ask for this String again, and CXF transports it > ("correcly wrong") back [because it is wrong in the HashMap]. But it is as > wrong, as it was stored in the HashMap - i hope you know what i mean. So > actually it looks like the Services transports the String correctly back, > but it fails at interpreting the String when it comes in. > > Any ideas? > > Concerning the JSP / Form issue: > I use tiles, where the main template starts like the following: > <%@ page contentType="text/html;charset=UTF-8" language="java"%> > <%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%> > <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html"%> > <%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t"%> > <%@ taglib uri="http://tiles.apache.org/tags-tiles"; prefix="tiles"%> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > <html> > <head> > <title><tiles:getAsString name="title" /></title> > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> > > This is included by all JSP's [well, actually the template is including the > JSP]. > > But as i said, after submitting a form, the String is correctly saved into > a Java Bean, so i don't think the problem might come out of THAT. > > --Daniel > > > -----Ursprüngliche Nachricht----- > Von: Benson Margulies [mailto:[email protected]] > Gesendet: Freitag, 30. Oktober 2009 12:54 > An: [email protected] > Betreff: Re: CXF Encoding Problem > > 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 > > > > > > > > >
