Hi Sergey,
Do these annotations apply to Provider based REST services? I have used these 
in JAX-RS services, but not for JAX-WS provider based stuff.
What I've done with XML payloads (payload mode) is
1. take the request xml, manually unmarshal using JAXB
2. process
3. create and return marshaled string as DataSource.

With attachments (I guess message mode), in your example, if I have a result in 
the form of JAXB root model object, how would I return a DataSource so that CXF 
can process the response into Multipart? I was thinking I have to build 
something like MultiPartDataSource manually.

-Vinay



-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]] 
Sent: Monday, May 20, 2013 4:59 PM
To: [email protected]
Subject: Re: REST with JAX-WS Provider: attachment support

Hi
On 20/05/13 21:28, Penmatsa, Vinay wrote:
> Hi,
> I have a REST service based on JAX-WS Provider and Dispatch (implementing 
> Provider<DataSource>). Until now, I accept/produce only XML. Now, I have to 
> support attachments.
> Now, it seems like request should be "multipart/related" as only 
> AttachmentInInterceptor is part of the chain by default. I could probably 
> change that to use AttachmentInputInterceptor instead. The question is how 
> can I can I return MultipartBody? Is there in-built support for that or 
> should I create my own DataSource and handle with an custom out interceptor?

Adding @Consumes("multipart/related") should be enough to get DataSource 
representing the root attachment, and similarly adding

@Produces("multipart/related") is nearly enough to get out DataSource 
converted to the multipart payload, except that you also need to specify 
the content type of this root type, so it can look like this:

@Produces("multipart/related;type=application/xml")
@Consumes("multipart/related")
public DataSource a(DataSource ds) {
     return ds;
}

My understanding you'd like to have a 100% portable code, right ?

Note that up to CXF 3.0-SNAPSHOT, the input 'ds' parameter will 
represent the root part of the incoming payload. The response DataSource 
also represents the root part of the outgoing attachment.
I think it is rarely that someone will want to have 'ds' (in this case) 
representing the actual non-parsed multipart payload or manually build 
the actual multipart body, so originally I went that path.

In CXF 3.0, due to JAX-RS 2.0 TCK 'insistence' on the types like 
DataSource, InputStream, byte[] be supported by basic pre-packaged 
providers, the above will slightly change to:

@Produces("multipart/related;type=application/xml")
@Consumes("multipart/related")
@Multipart
public DataSource a(@Multipart DataSource ds) {
     return ds;
}

Where CXF @Multipart annotation marks in and out parameters as multipart 
bodies. Without @Multipart the 1st example above will produce a portable 
but more complex code (meaning DataSource will have to be manually 
parsed or used to create the out payload manually)

Sergey


>
>
> Thanks,
> Vinay
>
>


Reply via email to