Thank you @Aki for the clarification. I'm now in a strong position to ask the people maintaining the third party system to change their WSDL as it is using none standard implementation.
For your last question, I think BizTalk uses the local charset to encode and decode the headers. The WSDL I'm tyring to use is already in production. Thank you again to all of you @Daniel and @Aki. Warm regards Younes Ouadi On Mon, Jun 23, 2014 at 2:22 PM, Aki Yoshida <[email protected]> wrote: > I think switching the encoding to iso-8859-1 won't solve the issue > because that won't be right. > > all headers are supposed to be encoded in US-ASCII. > http://tools.ietf.org/html/rfc2822#page-7 > Non ASCII values needed to be encoded using a special ASCII encoding > http://tools.ietf.org/html/rfc2047 > > We typically assume all headers are already encoded in ASCII for the > soap binding, so no special encoding is applied. > > BP-I doesn't talk about the valid soap action values, probably > assuming the same thing. > > I never encountered a non-ascii SOAPAction and I don't know what > exactly BizTalk is expecting (e.g., decoding using the local charset > or expecting the encoding scheme of rfc2047). > > > 2014-06-22 14:13 GMT+02:00 Younes Ouadi <[email protected]>: > > The whole sample, after modification, is attached to this e-mail. > > > > Warm regards. > > > > Younes > > > > > > > > On Sun, Jun 22, 2014 at 1:12 PM, Younes Ouadi <[email protected]> > > wrote: > >> > >> Hello Dears, > >> > >> I'm stuck with the Async Client and accented characters. Please help. > >> > >> As suggested by @Daniel, I have suitched to Async Client hoping to solve > >> my initial issue, that is: consuming a web service whose SOAPAction > contains > >> an accented character. > >> > >> To do so: > >> * I took the sample program that is distributed with CXF 2.7.11 > >> > (apache-cxf-2.7.11-src/distribution/src/main/release/samples/jaxws_async) > >> * I have add two interceptors one for the server and one for the client > >> (sorry, this is the first time I'm hooking into CXF and this is the > only way > >> I found to add arbitrary headers to CXF request). > >> * When the header doesn't contain accented characters, every thing works > >> well. The client initiate the request with the arbitrary header, the > server > >> receives the request along with the header, process it and sends back > the > >> response to the client. > >> * When the header contains an accented character, the client fail to > >> initiate the request with the error: > >> "java.util.concurrent.ExecutionException: > >> java.nio.charset.UnmappableCharacterException: Input length = 1" > >> * Googling this error shows (in other context of course) that there is > an > >> issue with the encoding. > >> * I tried to enforce the use of ISO-8859-1, but with no luck. > >> > >> The interceptor at the client side is as follows: > >> public class ClientHttpHeaderInterceptor extends > >> AbstractPhaseInterceptor<Message>{ > >> > >> public ClientHttpHeaderInterceptor() { > >> super(Phase.PREPARE_SEND); > >> } > >> > >> @Override > >> public void handleMessage(Message message) throws Fault { > >> // message.put(Message.CONTENT_TYPE, "text/xml; > >> charset=ISO-8859-1"); > >> // message.put(Message.ENCODING, "ISO-8859-1"); > >> > >> @SuppressWarnings("unchecked") > >> Map<String, List<String>> headers = (Map<String, > >> List<String>>)message.get(Message.PROTOCOL_HEADERS); > >> if ( headers != null ) { > >> List<String> header = new ArrayList<String>(); > >> header.add("Héader"); > >> > >> System.out.println("========================= Adding My > >> Header: " + header); > >> > >> headers.put("My Header", header); > >> > >> message.put(Message.PROTOCOL_HEADERS, headers); > >> } > >> } > >> } > >> > >> > >> The interceptor at the server side is as follows: > >> public class ServerHttpHeaderInterceptor extends > >> AbstractPhaseInterceptor<Message>{ > >> > >> public ServerHttpHeaderInterceptor() { > >> super(Phase.PRE_INVOKE); > >> } > >> > >> @Override > >> public void handleMessage(Message message) throws Fault { > >> @SuppressWarnings("unchecked") > >> Map<String, List<String>> headers = (Map<String, > >> List<String>>)message.get(Message.PROTOCOL_HEADERS); > >> if ( headers != null ) { > >> if ( headers.get("My Header") != null ) { > >> System.out.println("========================= Received > My > >> Header: " + headers.get("My Header").toString()); > >> } > >> else { > >> System.out.println("========================= Received > My > >> Header: none"); > >> } > >> } > >> } > >> } > >> > >> > >> Warm regards > >> > >> Younes > >> > >> > >> > >> > >> > >> > >> > >> On Sat, Jun 21, 2014 at 10:08 AM, Younes Ouadi <[email protected]> > >> wrote: > >>> > >>> Hi @Daniel, > >>> > >>> I appreciate very much your help. Thank you for the time, effort and > >>> attention you have devoted to this question. > >>> > >>> For your recommendation, I can't do much. The WSDL in question is > already > >>> in production consumed by a BizTalk-base client (the server is also a > >>> BizTalk based server, as you can see it in the WSDL). > >>> > >>> I will give a try to the Async Client and let you know the outcome. > >>> > >>> Warm regards > >>> > >>> Younes > >>> > >>> > >>> > >>> > >>> > >>> On Fri, Jun 20, 2014 at 5:29 PM, Daniel Kulp <[email protected]> wrote: > >>>> > >>>> > >>>> Looking at the code for the JDK: > >>>> > >>>> > >>>> > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding > >>>> > >>>> I see they intentionally leave it in whatever encoding it find with > the > >>>> “file.encoding” system property at startup providing all the ASCII > >>>> characters work. Kind of wrong if you ask me, but that does mean > that you > >>>> really can only rely on the ASCII level character being transferred > >>>> properly. > >>>> > >>>> Dan > >>>> > >>>> > >>>> On Jun 20, 2014, at 12:06 PM, Daniel Kulp <[email protected]> wrote: > >>>> > >>>> > > >>>> > Some bad news…. with a little bit of good news. > >>>> > > >>>> > The HttpURLConnection that CXF uses by default for sending requests > to > >>>> > the server always seems to use UTF-8. I checked with Java 6/7/8 > and they > >>>> > all do that. There doesn’t seem to be any way to make it behave > correctly. > >>>> > :-( If you can try creating an HttpURLConnection and calling > >>>> > setRequestProperty(“SOAPAction”, “Héader”) or something and doing a > >>>> > wireshark or similar, you’ll see it’s sending as UTF-8 encoded. > Seems to > >>>> > be a bug in the JDK. If you can figure out away to get it to > properly send > >>>> > the header, I’d love to see it. > >>>> > > >>>> > Both of the async clients we have (Netty on 3.0 and the Async client > >>>> > on both 2.7 and 3.0) seem to handle ISO-8859-1 headers properly. > Thus, you > >>>> > can add the appropriate dependencies and configure it to “aways” > use the > >>>> > async transport and it should transfer fine. > >>>> > > >>>> > HOWEVER - neither of those will handle any characters outside of > >>>> > 8859-1. They don’t encode the header using the RFC that’s there > for > >>>> > encoding headers outside of the 8859-1 code set. Thus, this still > isn’t a > >>>> > full solution. > >>>> > > >>>> > That all said, I’d STRONGLY STRONGLY encourage you to change the > >>>> > Action to NOT have those characters. Any client that uses the > JAX-WS > >>>> > reference implementation built into the JDK would also fail (due to > them > >>>> > also using the HttpURLConnection). > >>>> > > >>>> > > >>>> > Dan > >>>> > > >>>> > > >>>> > On Jun 20, 2014, at 4:42 AM, Younes Ouadi <[email protected]> > >>>> > wrote: > >>>> > > >>>> >> Hello Dears, > >>>> >> > >>>> >> I have an issue with soap-actions that contains accented charaters. > >>>> >> I'm > >>>> >> sure that this is not something new and it is possible that I'm > >>>> >> missing > >>>> >> something. So, please help. > >>>> >> > >>>> >> My case is as follows: > >>>> >> * I have received a WSDL of a third party system > >>>> >> * I have used wsdl2java maven plugin to generate classes > >>>> >> * I have setted up a client and a server using Spring method > >>>> >> * When I try to consume a service, the server reject my request > with: > >>>> >> 'The > >>>> >> given SOAPAction does not match an operation' > >>>> >> * The logs shows that the SOAPAction header: > >>>> >> ** at the client side contains the corrcet value which contain an > >>>> >> accented > >>>> >> character (the character 'é') > >>>> >> ** at the server side, it contains a wrong value (the 'é' is > replace > >>>> >> by two > >>>> >> other charaters) > >>>> >> > >>>> >> It looks like that CXF: > >>>> >> * at the client side, it hase encoded the the header value using > >>>> >> UTF-8 > >>>> >> * while at the the server side, it has decoded the header value > using > >>>> >> ISO-8859-1 > >>>> >> > >>>> >> I have asked this question on SO and I have got a reply saying that > >>>> >> as per > >>>> >> HTTP Specs, headers should be in ISO-8859-1. > >>>> >> > >>>> >> My question here is: how I can ask CXF to encode headers, at the > >>>> >> client > >>>> >> side, using ISO-8859-1 instead of UTF-8? > >>>> >> > >>>> >> My config is: > >>>> >> * OS: Fedora 19 > >>>> >> * JDK: Java(TM) SE Runtime Environment (build 1.6.0_33-b03) | Java > >>>> >> HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) > >>>> >> * CXF: 2.7.11 > >>>> >> > >>>> >> I have put all the detail of thsi case on SO. Please see ' > >>>> >> > >>>> >> > http://stackoverflow.com/questions/24305749/cxf-jaxws-endpoint-fail-with-the-given-soapaction-does-not-match-an-operation > >>>> >> '. > >>>> >> > >>>> >> Warm regards. > >>>> >> > >>>> >> Younes Ouadi > >>>> > > >>>> > -- > >>>> > Daniel Kulp > >>>> > [email protected] - http://dankulp.com/blog > >>>> > Talend Community Coder - http://coders.talend.com > >>>> > > >>>> > >>>> -- > >>>> Daniel Kulp > >>>> [email protected] - http://dankulp.com/blog > >>>> Talend Community Coder - http://coders.talend.com > >>>> > >>> > >> > > >
