Discussion:
CXF JaxWs Endpoint fail with 'The given SOAPAction does not match an operation' when the action contains accented characters
Younes Ouadi
2014-06-20 08:42:56 UTC
Permalink
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
2014-06-20 16:06:38 UTC
Permalink
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
Post by Younes Ouadi
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.
* 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'
** 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)
* 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?
* 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
dkulp-1oDqGaOF3Lkdnm+***@public.gmane.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Daniel Kulp
2014-06-20 16:29:31 UTC
Permalink
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
Post by Daniel Kulp
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
Post by Younes Ouadi
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.
* 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'
** 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)
* 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?
* 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
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp-1oDqGaOF3Lkdnm+***@public.gmane.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Younes Ouadi
2014-06-21 09:08:41 UTC
Permalink
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
Post by Daniel Kulp
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
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
Post by Younes Ouadi
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.
* 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
'The
Post by Younes Ouadi
given SOAPAction does not match an operation'
** at the client side contains the corrcet value which contain an
accented
Post by Younes Ouadi
character (the character 'é')
** at the server side, it contains a wrong value (the 'é' is replace by
two
Post by Younes Ouadi
other charaters)
* 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
Post by Younes Ouadi
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?
* 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
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Younes Ouadi
2014-06-22 12:12:22 UTC
Permalink
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
Post by Younes Ouadi
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
Post by Daniel Kulp
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
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
Post by Younes Ouadi
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.
* 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
'The
Post by Younes Ouadi
given SOAPAction does not match an operation'
** at the client side contains the corrcet value which contain an
accented
Post by Younes Ouadi
character (the character 'é')
** at the server side, it contains a wrong value (the 'é' is replace
by two
Post by Younes Ouadi
other charaters)
* 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
Post by Younes Ouadi
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?
* 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
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Younes Ouadi
2014-06-22 12:13:41 UTC
Permalink
The whole sample, after modification, is attached to this e-mail.

Warm regards.

Younes
Post by Younes Ouadi
Hello Dears,
I'm stuck with the Async Client and accented characters. Please help.
my initial issue, that is: consuming a web service whose SOAPAction
contains an accented character.
* 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
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.
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);
}
}
}
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
Post by Younes Ouadi
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
Post by Daniel Kulp
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
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
Post by Younes Ouadi
Hello Dears,
I have an issue with soap-actions that contains accented charaters.
I'm
Post by Younes Ouadi
sure that this is not something new and it is possible that I'm
missing
Post by Younes Ouadi
something. So, please help.
* 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
'The
Post by Younes Ouadi
given SOAPAction does not match an operation'
** at the client side contains the corrcet value which contain an
accented
Post by Younes Ouadi
character (the character 'é')
** at the server side, it contains a wrong value (the 'é' is replace
by two
Post by Younes Ouadi
other charaters)
* 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
Post by Younes Ouadi
HTTP Specs, headers should be in ISO-8859-1.
My question here is: how I can ask CXF to encode headers, at the
client
Post by Younes Ouadi
side, using ISO-8859-1 instead of UTF-8?
* 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
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Aki Yoshida
2014-06-23 13:22:26 UTC
Permalink
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).
Post by Younes Ouadi
The whole sample, after modification, is attached to this e-mail.
Warm regards.
Younes
Post by Younes Ouadi
Hello Dears,
I'm stuck with the Async Client and accented characters. Please help.
my initial issue, that is: consuming a web service whose SOAPAction contains
an accented character.
* 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
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.
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);
}
}
}
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
Post by Younes Ouadi
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
Post by Daniel Kulp
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
Post by Daniel Kulp
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
Post by Younes Ouadi
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.
* 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'
** 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)
* 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?
* 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
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Younes Ouadi
2014-06-23 14:50:58 UTC
Permalink
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
Post by Aki Yoshida
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).
Post by Younes Ouadi
The whole sample, after modification, is attached to this e-mail.
Warm regards.
Younes
Post by Younes Ouadi
Hello Dears,
I'm stuck with the Async Client and accented characters. Please help.
my initial issue, that is: consuming a web service whose SOAPAction
contains
Post by Younes Ouadi
Post by Younes Ouadi
an accented character.
* 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)
Post by Younes Ouadi
Post by Younes Ouadi
* 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
Post by Younes Ouadi
Post by Younes Ouadi
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
Post by Younes Ouadi
Post by Younes Ouadi
receives the request along with the header, process it and sends back
the
Post by Younes Ouadi
Post by Younes Ouadi
response to the client.
* When the header contains an accented character, the client fail to
java.nio.charset.UnmappableCharacterException: Input length = 1"
* Googling this error shows (in other context of course) that there is
an
Post by Younes Ouadi
Post by Younes Ouadi
issue with the encoding.
* I tried to enforce the use of ISO-8859-1, but with no luck.
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);
}
}
}
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
Post by Younes Ouadi
Post by Younes Ouadi
Header: " + headers.get("My Header").toString());
}
else {
System.out.println("========================= Received
My
Post by Younes Ouadi
Post by Younes Ouadi
Header: none");
}
}
}
}
Warm regards
Younes
Post by Younes Ouadi
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
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
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
I see they intentionally leave it in whatever encoding it find with
the
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
“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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
really can only rely on the ASCII level character being transferred
properly.
Dan
Some bad news
. with a little bit of good news.
The HttpURLConnection that CXF uses by default for sending requests
to
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
the server always seems to use UTF-8. I checked with Java 6/7/8
and they
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
all do that. There doesn’t seem to be any way to make it behave
correctly.
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
:-( 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
be a bug in the JDK. If you can figure out away to get it to
properly send
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
can add the appropriate dependencies and configure it to “aways”
use the
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
encoding headers outside of the 8859-1 code set. Thus, this still
isn’t a
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
reference implementation built into the JDK would also fail (due to
them
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
also using the HttpURLConnection).
Dan
Post by Younes Ouadi
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.
* 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
'The
given SOAPAction does not match an operation'
** 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Younes Ouadi
by two
other charaters)
* 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Younes Ouadi
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?
* 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Aki Yoshida
2014-06-24 17:22:05 UTC
Permalink
Hi Younes,
yes. I think that would be a good approach.
If BizTalks is using the local charset, it can't even interoperate
with each other beyond the iso-latin-1 boarders.

That means, definitely they should consider changing the soapaction value.
regards, aki
Post by Younes Ouadi
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.
Warm regards
Younes Ouadi
Post by Aki Yoshida
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).
Post by Younes Ouadi
The whole sample, after modification, is attached to this e-mail.
Warm regards.
Younes
Post by Younes Ouadi
Hello Dears,
I'm stuck with the Async Client and accented characters. Please help.
my initial issue, that is: consuming a web service whose SOAPAction
contains
Post by Younes Ouadi
Post by Younes Ouadi
an accented character.
* 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)
Post by Younes Ouadi
Post by Younes Ouadi
* 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
Post by Younes Ouadi
Post by Younes Ouadi
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
Post by Younes Ouadi
Post by Younes Ouadi
receives the request along with the header, process it and sends back
the
Post by Younes Ouadi
Post by Younes Ouadi
response to the client.
* When the header contains an accented character, the client fail to
java.nio.charset.UnmappableCharacterException: Input length = 1"
* Googling this error shows (in other context of course) that there is
an
Post by Younes Ouadi
Post by Younes Ouadi
issue with the encoding.
* I tried to enforce the use of ISO-8859-1, but with no luck.
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);
}
}
}
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
Post by Younes Ouadi
Post by Younes Ouadi
Header: " + headers.get("My Header").toString());
}
else {
System.out.println("========================= Received
My
Post by Younes Ouadi
Post by Younes Ouadi
Header: none");
}
}
}
}
Warm regards
Younes
Post by Younes Ouadi
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
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
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
I see they intentionally leave it in whatever encoding it find with
the
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
“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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
really can only rely on the ASCII level character being transferred
properly.
Dan
Post by Daniel Kulp
Some bad news…. with a little bit of good news.
The HttpURLConnection that CXF uses by default for sending requests
to
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
the server always seems to use UTF-8. I checked with Java 6/7/8
and they
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
all do that. There doesn’t seem to be any way to make it behave
correctly.
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
:-( 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
be a bug in the JDK. If you can figure out away to get it to
properly send
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
can add the appropriate dependencies and configure it to “aways”
use the
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
encoding headers outside of the 8859-1 code set. Thus, this still
isn’t a
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
reference implementation built into the JDK would also fail (due to
them
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
also using the HttpURLConnection).
Dan
Post by Younes Ouadi
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.
* 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
'The
given SOAPAction does not match an operation'
** 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
Post by Younes Ouadi
by two
other charaters)
* 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
Post by Younes Ouadi
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?
* 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
Post by Younes Ouadi
Post by Younes Ouadi
Post by Younes Ouadi
Post by Daniel Kulp
Post by Daniel Kulp
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
Daniel Kulp
2014-06-25 19:36:10 UTC
Permalink
Post by Younes Ouadi
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
Post by Younes Ouadi
initial issue, that is: consuming a web service whose SOAPAction contains
an accented character.
* 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
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.
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");
" + header);
headers.put("My Header", header);
message.put(Message.PROTOCOL_HEADERS, headers);
}
}
}
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
Post by Younes Ouadi
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
Post by Daniel Kulp
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
Post by Daniel Kulp
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.
Post by Daniel Kulp
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.
Post by Daniel Kulp
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.
Post by Daniel Kulp
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).
Post by Daniel Kulp
Dan
Post by Younes Ouadi
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.
* 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
'The
Post by Daniel Kulp
Post by Younes Ouadi
given SOAPAction does not match an operation'
** at the client side contains the corrcet value which contain an
accented
Post by Daniel Kulp
Post by Younes Ouadi
character (the character 'é')
** at the server side, it contains a wrong value (the 'é' is replace
by two
Post by Daniel Kulp
Post by Younes Ouadi
other charaters)
* 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
Post by Daniel Kulp
Post by Younes Ouadi
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?
* 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
Post by Daniel Kulp
Post by Younes Ouadi
'.
Warm regards.
Younes Ouadi
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dkulp-1oDqGaOF3Lkdnm+***@public.gmane.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Loading...