Can you retry with 2.1.7?
There was a bug in the attachment deserializer that was causing it to not
reset the message encoding to the encoding in the part. Basically, it always
used the encoding from the HTTP header (which, in your case, there wasn't one
so defaulted to ISO-8859-1 as per HTTP spec). With 2.1.7, this was fixed to
pull the charset from from the mime header for the root part and reset
properly.
Dan
On Fri October 30 2009 8:48:15 am Daniel Weidele 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="<root.mess...@cxf.apache.org>"; 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="<root.mess...@cxf.apache.org>"; 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: <root.mess...@cxf.apache.org>
>
> <soap:Envelope
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><createCol
> lectionRequest
> xmlns="..."><auth>...</auth><user_id>D0815</user_id><collection_name>TESTÜ
> ÖÜßTEST</collection_name><user_notification>true</user_notification></creat
> eCollectionRequest></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="<root.mess...@cxf.apache.org>"; 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: <root.mess...@cxf.apache.org>
>
> <soap:Envelope
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><createCol
> lectionResponse
> xmlns="..."><collection_id>3</collection_id></createCollectionResponse></s
> oap: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="<root.mess...@cxf.apache.org>"; 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="<root.mess...@cxf.apache.org>"; 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: <root.mess...@cxf.apache.org>
>
> <soap:Envelope
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><listColle
> ctionRequest
> xmlns="..."><auth>...</auth><user_id>D0815</user_id></listCollectionReques
> t></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="<root.mess...@cxf.apache.org>"; 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: <root.mess...@cxf.apache.org>
>
> <soap:Envelope
> xmlns:soap="http://www.w3.org/2003/05/soap-envelope";><soap:Body><listColle
> ctionResponse
> xmlns="..."><item><collection_id>3</collection_id><user_id>D0815</user_id>
> <collection_name>TEST?œ?–?œ?ŸTEST</collection_name><cre
> ation_date>2009-10-30T00:00:00.000Z</creation_date><user_notification>true<
> /user_notification><modification_date>2009-10-30T00:00:00.000Z</modificatio
> n_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:bimargul...@gmail.com]
> Gesendet: Freitag, 30. Oktober 2009 13:35
> An: users@cxf.apache.org
> 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 <weid...@esteam.de> 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:bimargul...@gmail.com]
> > Gesendet: Freitag, 30. Oktober 2009 12:54
> > An: users@cxf.apache.org
> > 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 <weid...@esteam.de> 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:bimargul...@gmail.com]
> > > Gesendet: Freitag, 30. Oktober 2009 11:30
> > > An: users@cxf.apache.org
> > > 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 <weid...@esteam.de>
> >
> > 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
>
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
