[
https://issues.apache.org/jira/browse/CXF-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622373#action_12622373
]
Daniel Kulp commented on CXF-1668:
----------------------------------
1) "how JMS handles TextMessages internally" : this is JMS vendor specific.
Most likely, they call getBytes() or something based on a negotiated charset
(maybe utf8) or similar. Basically, the JMS spec just says if it's a
TextMessage, the String has to end up the same coming out as what went in.
The vendors are free to do any sort of optimization as long as that requirement
is met. (example: strings are normally very compressible, so maybe a gzip of
them on the wire) Don't know about the C++ thing.
2)
inMessage.setContent(StringReader.class, new StringReader(response));
should just be:
inMessage.setContent(Reader.class, new StringReader(response));
so other implementations of Reader could be used.
3) "Readers and Writers influence the behaviour of other interceptors?" -
Yes. I kind of thought about this after I wrote the first comment. The MAIN
impact would be that MTOM and Soap w/ attachements probably won't work anymore
as they require the output streams due to the binary nature.
LoggingInterceptors wouldn't work either. Those interceptors would probably
need some work as well.
That all said, it definitely sounds like more of a 2.2 thing and not a 2.1.x
patch thing.
> Wrong encoding using JMS Transport
> ----------------------------------
>
> Key: CXF-1668
> URL: https://issues.apache.org/jira/browse/CXF-1668
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.1
> Environment: MS Windows XP, Sun Solaris
> Reporter: Eduard Hildebrandt
>
> In class JMSConduit getBytes() is used to transform the string in a byte
> array.
> byte[] bytes = null;
> if (response instanceof String) {
> String requestString = (String)response;
> bytes = requestString.getBytes();
> } else {
> bytes = (byte[])response;
> }
> getBytes() uses the standard encoding of the plattform. This is wrong because
> the encoding of the message must be used.
> I have written an interceptor as workaround to solve this issue:
> public class EncodingInterceptor extends AbstractPhaseInterceptor<Message> {
> public EncodingInterceptor() {
> super(Phase.RECEIVE);
> }
> public void handleMessage(Message message) {
> try {
> InputStream inputStream = message.getContent(InputStream.class);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> while (true) {
> int datum = inputStream.read();
> if (datum == -1)
> break;
> baos.write(datum);
> }
> String string = baos.toString();
> ByteArrayInputStream bais = new
> ByteArrayInputStream(string.getBytes("UTF-8"));
> message.setContent(InputStream.class, bais);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> public void handleFault(Message messageParam) {
> }
> }
> But the issue should be solved in JMSConduit class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
