On Jun 22, 2014, at 8:12 AM, Younes Ouadi <[email protected]> wrote:
> Hello Dears, > > I'm stuck with the Async Client and accented characters. Please help. Sorry, wasn’t clear. You need to use the HTTP transport based on the Apache HTTP Components async clients. Some docs at: http://cxf.apache.org/docs/asynchronous-client-http-transport.html Code would remain exactly the same as before except for the line: bp.getRequestContext().put("use.async.http.conduit", Boolean.TRUE); If the appropriate async libraries are found on the classpath (if using Maven, add cxf-rt-transports-http-hc and it should handle everything else), that should be all that’s needed. Dan > > 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 >>> >>> >> -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
