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
> >
> >
>
