Sergey,

When did you do this, just now? I'm reading

org.apache.cxf.jaxrs.provider.MultipartProvider.readFrom(Class<Object>,
Type, Annotation[], MediaType, MultivaluedMap<String, String>,
InputStream)

from 2.5.0 and it throws a naked WebApplicationException.

I think you've also accidentally answered another question:

Can I define a mapper on 'WebApplicationException' itself without fear
of recursion?


On Thu, Nov 24, 2011 at 6:10 AM, Sergey Beryozkin <[email protected]> wrote:
> Hi Benson
> On 24/11/11 03:03, Benson Margulies wrote:
>>
>> Situation:
>>
>> I'm using jquery forms to submit a multipart to a JAX-RS service. So,
>> JQuery is using an iframe, and as a result error responses disappear.
>> All I get to see is the entity.
>>
>> If I make a mistake such that CXF generates a WebApplicationException
>>
>> e.g.
>>
>> 2011-11-23 21:59:09,885 [http-bio-15000-exec-30] WARN
>> org.apache.cxf.jaxrs.utils.JAXRSUtils - No multipart with content id
>> btArch found, request content type :
>> multipart/form-data;boundary=----WebKitFormBoundary1JsUh4wyAbhxFGfC
>> 2011-11-23 21:59:09,885 [http-bio-15000-exec-30] WARN
>> org.apache.cxf.jaxrs.impl.WebApplicationExceptionMapper -
>> WebApplicationException has been caught : no cause is available
>>
>> then there's no entity.
>>
>> Is there some sort of exception mapper I can use to add some payload
>> to this case to indicate the error?
>
> I've added MultipartReadException which captures an expected id,
> content-type (if any) and the error message, and it's wrapped in
> WebApplicationException. So by default the error text content being
> returned.
> You can customize it by registering your own WebApplicationException mapper,
> check the exception cause, if MultipartReadException - work with it,
> otherwise return the available WebApplicationException Response or create
> some default Response - you may wish to delegate to the default
> WebApplicationExceptionMapper; another option - override
> MultipartProvider.readFrom and customize WebApplicationException earlier.
>
> The reason I thought MultipartReadException was worth wrapping was that
> users would otherwise get the stacktraces back unless a custom
> MultipartReadException is registered
>
> Cheers, Sergey
>

Reply via email to