data seems corrupt in versions after 3.0.0-milestone2

[ltouve <la...@soteradefense.com>]

I have a simple client that uses a WebClient to get jpg data from a REST
service:
 
  byte[] bytes = client.path("somepath").get(byte[].class);

When I use the following dependency:

         <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-rs-client</artifactId>
            <version>3.0.0-milestone2</version>
        </dependency>

Everything works fine.  If I change the version to anything later than that,
the bytes that are returned appear to be somewhat corrupted (it looks like
extended characters are affected).  I can't tell if the encoding is off or
what, but I've tried setting the Encoding (UTF-8 & UTF-16) and the MimeType
(application/octet-stream), but nothing seems to make a difference.  I
modified the code and tried:

  Response response = client.path("somepath").get();
  byte[] bytes = response.readEntity(byte[].class);

So I can examine the response headers, and they are identical when comparing
using version 3.0.0-milestone2 to any of the other versions.  When using the
milestone version, the response header indicates that the encoding is UTF-8.

Is there a different approach that I should use to retrieve raw data?



--
View this message in context: http://cxf.547215.n5.nabble.com/data-seems-corrupt-in-versions-after-3-0-0-milestone2-tp5781395.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: data seems corrupt in versions after 3.0.0-milestone

[ltouve <la...@soteradefense.com>]

Sergey Beryozkin wrote
> You can try
> 
> response.readEntity(InputStream.class) and extract the byte[] from it as 
> required.

Thank you!  This did the trick. 

Larry



--
View this message in context: http://cxf.547215.n5.nabble.com/data-seems-corrupt-in-versions-after-3-0-0-milestone2-tp5781395p5781433.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: data seems corrupt in versions after 3.0.0-milestone

[Sergey Beryozkin <sb...@gmail.com>]

You can try

response.readEntity(InputStream.class) and extract the byte[] from it as 
required.
Or if String is expected then try

response.readEntity(String.class)

The way byte[] is converted in 3.0.0-milestone2 is as follows:

https://github.com/apache/cxf/blob/cxf-3.0.0-milestone2/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/BinaryDataProvider.java#L79

No media type charset parameter is checked

In the latest CXF 3.1.11 it is checked:

https://github.com/apache/cxf/blob/cxf-3.1.11/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/provider/BinaryDataProvider.java#L9

if none is available then it will read the same way as in 
3.0.0-milestone2, however if it is available then it wraps InputStream 
into InputStreamReader with a specified charset, reads it into String 
and then get the bytes from it.

Hmm... I'm not sure this copying around is a good idea at all, though I 
do not see how it can get the wrong result in the end...

I just got rid of it as part of CXF-7424, though this test

http://git-wip-us.apache.org/repos/asf/cxf/commit/f5e8457e

was passing even when I had a content-type set to include a charset (=> 
exercising the redundant conversion branch) - perhaps in some cases it 
can still cause issues.

So for now read from InputStream...

Sergey




On 22/06/17 04:28, ltouve wrote:
> I have a simple client that uses a WebClient to get jpg data from a REST
> service:
>   
>    byte[] bytes = client.path("somepath").get(byte[].class);
> 
> When I use the following dependency:
> 
>           <dependency>
>              <groupId>org.apache.cxf</groupId>
>              <artifactId>cxf-rt-rs-client</artifactId>
>              <version>3.0.0-milestone2</version>
>          </dependency>
> 
> Everything works fine.  If I change the version to anything later than that,
> the bytes that are returned appear to be somewhat corrupted (it looks like
> extended characters are affected).  I can't tell if the encoding is off or
> what, but I've tried setting the Encoding (UTF-8 & UTF-16) and the MimeType
> (application/octet-stream), but nothing seems to make a difference.  I
> modified the code and tried:
> 
>    Response response = client.path("somepath").get();
>    byte[] bytes = response.readEntity(byte[].class);
> 
> So I can examine the response headers, and they are identical when comparing
> using version 3.0.0-milestone2 to any of the other versions.  When using the
> milestone version, the response header indicates that the encoding is UTF-8.
> 
> Is there a different approach that I should use to retrieve raw data?
> 
> 
> 
> --
> View this message in context: http://cxf.547215.n5.nabble.com/data-seems-corrupt-in-versions-after-3-0-0-milestone2-tp5781395.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>