I need Dan Kulp's help at this point, I'm not sure if I'm right that that Encoding: ISO... is a problem.
On Fri, Oct 30, 2009 at 8:48 AM, Daniel Weidele <[email protected]> wrote: > (1) Alright so this what the client sent tot he server when creating a > "Composition". You can find the problematic String at the Tag > "collection_name". This is what i want to SAVE at service side. > > 30.10.2009 13:40:06 org.apache.cxf.interceptor.LoggingInInterceptor logging > INFO: Inbound Message > ---------------------------- > ID: 30 > Address: /onnoTest > Encoding: ISO-8859-1 > Content-Type: multipart/related; type="application/xop+xml"; > boundary="uuid:eba158e1-d921-4f94-984a-2af2ce274330"; start="< > [email protected]>"; start-info="application/soap+xml"; > action="createCollection" > Headers: {Content-Length=[1059], Host=[localhost:8081], User-Agent=[Apache > CXF 2.1.6], connection=[keep-alive], Pragma=[no-cache], > content-type=[multipart/related; type="application/xop+xml"; > boundary="uuid:eba158e1-d921-4f94-984a-2af2ce274330"; start="< > [email protected]>"; start-info="application/soap+xml"; > action="createCollection"], Cache-Control=[no-cache], Accept=[*/*]} > Payload: > --uuid:eba158e1-d921-4f94-984a-2af2ce274330 > Content-Type: application/xop+xml; charset=UTF-8; > type="application/soap+xml"; action="createCollection"; > Content-Transfer-Encoding: binary > Content-ID: <[email protected]> > > <soap:Envelope > xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><createCollectionRequest > xmlns="..."><auth>...</auth><user_id>D0815</user_id><collection_name>TESTÜÖÜßTEST</collection_name><user_notification>true</user_notification></createCollectionRequest></soap:Body></soap:Envelope> > --uuid:eba158e1-d921-4f94-984a-2af2ce274330-- > > > > (2) This is what the service responses tot he client, after having saved. > Before this message appears, the String from the last message is already > saved wrongly coded into the Hash Map. > > -------------------------------------- > 30.10.2009 13:40:15 > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose > INFO: Outbound Message > --------------------------- > ID: 30 > Encoding: ISO-8859-1 > Content-Type: multipart/related; type="application/xop+xml"; > boundary="uuid:30418d54-1340-4b50-aa62-08c5b4c51b2e"; start="< > [email protected]>"; start-info="application/soap+xml" > Headers: {} > Payload: > --uuid:30418d54-1340-4b50-aa62-08c5b4c51b2e > Content-Type: application/xop+xml; charset=UTF-8; > type="application/soap+xml"; > Content-Transfer-Encoding: binary > Content-ID: <[email protected]> > > <soap:Envelope > xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><createCollectionResponse > xmlns="..."><collection_id>3</collection_id></createCollectionResponse></soap:Body></soap:Envelope> > --uuid:30418d54-1340-4b50-aa62-08c5b4c51b2e-- > -------------------------------------- > > > > (3) Now the client wants to get the String back again from the service, and > therefore sends the following tot he service: > > 30.10.2009 13:40:15 org.apache.cxf.interceptor.LoggingInInterceptor logging > INFO: Inbound Message > ---------------------------- > ID: 31 > Address: /onnoTest > Encoding: ISO-8859-1 > Content-Type: multipart/related; type="application/xop+xml"; > boundary="uuid:fb8fa002-6003-444a-a389-1fa4fb0028fc"; start="< > [email protected]>"; start-info="application/soap+xml"; > action="listCollection" > Headers: {Content-Length=[959], Host=[localhost:8081], User-Agent=[Apache > CXF 2.1.6], connection=[keep-alive], Pragma=[no-cache], > content-type=[multipart/related; type="application/xop+xml"; > boundary="uuid:fb8fa002-6003-444a-a389-1fa4fb0028fc"; start="< > [email protected]>"; start-info="application/soap+xml"; > action="listCollection"], Cache-Control=[no-cache], Accept=[*/*]} > Payload: > --uuid:fb8fa002-6003-444a-a389-1fa4fb0028fc > Content-Type: application/xop+xml; charset=UTF-8; > type="application/soap+xml"; action="listCollection"; > Content-Transfer-Encoding: binary > Content-ID: <[email protected]> > > <soap:Envelope > xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><listCollectionRequest > xmlns="..."><auth>...</auth><user_id>D0815</user_id></listCollectionRequest></soap:Body></soap:Envelope> > --uuid:fb8fa002-6003-444a-a389-1fa4fb0028fc-- > -------------------------------------- > > > > (4) So that here the server comes up with the wrong String (of course, > because it was wrong saved before in step after Step (1)) - Tag is > "collection_name" again: > > 30.10.2009 13:40:16 > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback onClose > INFO: Outbound Message > --------------------------- > ID: 31 > Encoding: ISO-8859-1 > Content-Type: multipart/related; type="application/xop+xml"; > boundary="uuid:4a802ac7-f75b-4474-a7a1-dfaa70ec0d12"; start="< > [email protected]>"; start-info="application/soap+xml" > Headers: {} > Payload: > --uuid:4a802ac7-f75b-4474-a7a1-dfaa70ec0d12 > Content-Type: application/xop+xml; charset=UTF-8; > type="application/soap+xml"; > Content-Transfer-Encoding: binary > Content-ID: <[email protected]> > > <soap:Envelope > xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><listCollectionResponse > xmlns="..."><item><collection_id>3</collection_id><user_id>D0815</user_id><collection_name>TEST?œ?–?œ?ŸTEST</collection_name><creation_date>2009-10-30T00:00:00.000Z</creation_date><user_notification>true</user_notification><modification_date>2009-10-30T00:00:00.000Z</modification_date></item></listCollectionResponse></soap:Body></soap:Envelope> > --uuid:4a802ac7-f75b-4474-a7a1-dfaa70ec0d12-- > -------------------------------------- > > > As you can see, in all 4 messages the "Encoding" is set to "ISO", but > inside the Payload the "charset" is set to "UTF-8". > > --Daniel > > -----Ursprüngliche Nachricht----- > Von: Benson Margulies [mailto:[email protected]] > Gesendet: Freitag, 30. Oktober 2009 13:35 > An: [email protected] > Betreff: Re: CXF Encoding Problem > > 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 > > > > > > > > > > > > > >
