Hi Benson
On 21/07/12 21:24, Benson Margulies wrote:
I tried to create two methods as follows:
@Path("/documentView")
@Consumes("multipart/form-data")
@Produces("text/html") // required to work the iframe trick.
@POST
public Response documentViewMultipart(@Description(value = "Json
specification of the processing options.", target = DocTarget.PARAM)
@Multipart(value =
"options") String optionsString,
@Description(value = "Input
text", target = DocTarget.PARAM)
@Multipart(value = "data")
InputStream data)
and
@Path("/documentView")
@Consumes("application/json")
@Produces("application/json")
@POST
public Response documentView(PlainTextInputOptions ptio)
when the browser sends a multipart POST to the URL, CXF tries (and
fails) to invoke the later instead of the former. Obviously I'll
change a path to get around this.
I've done a quick test as I happen to have a demo where a
multipart/form-data is expected.
In my case I can see the following on the wire:
Content-Type: multipart/form-data;
boundary=---------------------------1584578384211000436776668661
Accept=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
what happens next is the runtime will sort the accepts and start from
the first one (text/html) and check if candidates for it are available.
If yes (and assuming all other checks pass) then the check won't
continue because the first matching accept type in the sorted list will
be the right one for the client (text/html in this case).
I can think that the only reason you see a method producing
"application/json" preferred to the one producing "text/html" is that
the Accept originating from a browser have both "text/html" "&
application/json" as equal priority media types.
Can you log Accept produced by the browser please ?
Cheers, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
