Bryant, Thanks for the clarification.
I believe the provider (MBW) should be matched based on the entity type before writing to the stream. In this case, the AcceptHeaderHandler could not match the provider specific mime type and defaults to application/octet-stream. -Arul On 12/5/09, Bryant Luk <[email protected]> wrote: > Hi, > > Interesting blog entry! > > I believe what's happening for you is that since you didn't specify a > Content-Type via resource.contentType(), Wink defaults to > "application/octet-stream". Then, since you specified "text/xml" as > your @Produces value, then it wouldn't find your SOAPMessage entity > provider since application/octet-stream and text/xml aren't > compatible. > > An optional/system handler could be added to Wink that finds a > "better" media type that works more like what you expect. I'm > thinking something like the server side JAX-RS algorithm for finding > media types when not specified? > > On Sat, Dec 5, 2009 at 2:36 PM, Arulazi Dhesiaseelan > <[email protected]> wrote: >> Hello, >> >> I was playing with the Wink client recently and was quite impressed with >> it >> so far. >> >> I had a quick question though: >> >> I have written custom providers to handle SOAP messages on the client. I >> have annotated my providers with >> @Consumes(MediaType.TEXT_XML) >> @Produces(MediaType.TEXT_XML) >> >> But, when I post the request, I need to still specify the contentType as >> shown below, otherwise it would fail to resolve my MessageBodyWriter. >> >> // issue the request >> ClientResponse cr = >> resource.contentType("text/xml").post(ClientResponse.class, message); >> message = cr.getEntity(SOAPMessage.class); >> >> I expect this to work: >> ClientResponse cr = resource.post(ClientResponse.class, message); >> message = cr.getEntity(SOAPMessage.class); >> >> Any thoughts? >> >> You can find a fully working example in my blog entry [1]. >> >> -Arul >> >> [1] http://aruld.info/soap-over-resty-client/ >> > -- http://aruld.info
