Hi Sergei,

Currently I resolved that using Client API, but WADL-first support can be a 
good option for the future.

Regards,
Andrei.

> -----Original Message-----
> From: Sergey Beryozkin [mailto:[email protected]]
> Sent: Freitag, 7. April 2017 12:09
> To: [email protected]
> Subject: Re: Multipart body with proxy client
> 
> On 04/04/17 21:31, Sergey Beryozkin wrote:
> > Hi Andrei
> >
> > I checked the code, setting the contextual property
> > "support.type.as.multipart" should be enough as long as the type is a
> > built-in type like InputStream.
> >
> > I also can see @Multipart annotations can be added for the input
> > params, but not as a method annotation
> Sorry just need to clarify - it can be added as a method annotation manually,
> but not with the WADL-first approach yet (can be done only for input params
> for WADL-first, I recall Alexey Marchenko contributed)
> 
> Sergey
> 
> >
> > Thanks, Sergey
> >
> > On 04/04/17 16:24, Andrei Shakirin wrote:
> >> Hi Sergey,
> >>
> >> Thanks for the answer.
> >>
> >> Regarding @Multipart method annotation, is there any way to initiate
> >> generation of this annotation through the WADL? (project uses WADL
> >> fist approach)
> >>
> >> Regards,
> >> Andrei.
> >>
> >>> -----Original Message-----
> >>> From: Sergey Beryozkin [mailto:[email protected]]
> >>> Sent: Dienstag, 4. April 2017 16:53
> >>> To: [email protected]
> >>> Cc: Sergey Beryozkin; Dmitry Tsybulko
> >>> Subject: Re: Multipart body with proxy client
> >>>
> >>> Hi Andriy
> >>>
> >>> What changed in JAX-RS 2.0, and which annoyed me quite a bit at a
> >>> time, was that in JAX-RS 2.0 native types like InputStream have to
> >>> be processed by the default handlers, ex, in case of InputStream it
> >>> would be basically IOUtils.copy, etc, which started breaking the
> >>> attachments code where individual part was represented as
> >>> InputStream or String for ex. That was done to support wildcard
> >>> handlers like Jackson which would blindly accept any type as long as
> >>> it is application/json.
> >>>
> >>> InpputStream parts can still be supported by CXF RS multipart code
> >>> but as long as they have @Multipart annotations.
> >>>
> >>> I can assume that the reason the code below fails is because an
> >>> individual Attachment is using InputStream.
> >>>
> >>> Try adding @Multipart method annotation, without any properties,
> >>> that should help
> >>>
> >>> Thanks, Sergey
> >>>
> >>>
> >>>
> >>>
> >>> On 04/04/17 15:18, Andrei Shakirin wrote:
> >>>> Hi Sergey,
> >>>>
> >>>> I have discovered one difference in processing of mutipart body by
> >>>> client
> >>> proxy after migration to CXF 3:
> >>>>
> >>>> 1. Server method described by following interface (generated from
> >>>> WADL):
> >>>>   @GET
> >>>>   @Produces("multipart/mixed")
> >>>>   @Path
> >>>>   Response getSomething();
> >>>>
> >>>> 2. Implementation :
> >>>>   Response getSomething() {
> >>>>            MyResponse myResponse;// init it here
> >>>>            List<Attachment> attachments = new LinkedList<>();
> >>>>            attachments.add(new Attachment("response",
> >>> MediaType.APPLICATION_XML_TYPE.toString(), myResponse));
> >>>>           // it can be added other attachments
> >>>>           return Response.ok().entity(attachments).build();
> >>>>   }
> >>>>
> >>>> 3.  On client side we create service proxy for calling the method
> >>>>     final T serviceProxy = JAXRSClientFactory.create(baseURL +
> >>>> serviceURL,
> >>> serviceClass, new ArrayList<>(), features, null);
> >>>>     Response response = serviceProxy.getSomething();
> >>>>     MyResponse myResponse = response.readEntity(MyResponse.class);
> >>>>
> >>>> It works for CXF 2.7.11, but for CXF 3.1.7 we get following exception:
> >>>> javax.ws.rs.client.ResponseProcessingException: No message body
> >>>> reader has
> >>> been found for class MyResponse, ContentType:
> >>> multipart/mixed;boundary="uuid:e7578110-29f1-4125-848e-
> dc9230887d45".
> >>>>
> >>>> For CXF 3.1.7 code works without problems if we use Client API to
> >>>> read set of
> >>> attachments.
> >>>>
> >>>> Do you have any ideas why it works differently? It is not a big
> >>>> issue, because
> >>> WebClient / Client API works - anyway interesting to understand the
> >>> difference.
> >>>>
> >>>> Regards,
> >>>> Andrei.
> >>>>
> >>>
> >>>
> >>> --
> >>> Sergey Beryozkin
> >>>
> >>> Talend Community Coders
> >>> http://coders.talend.com/
> >
> 

Reply via email to