[
https://issues.apache.org/jira/browse/CXF-6155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nigel Hannam reopened CXF-6155:
-------------------------------
Apologies for reopening this issue, but having re-read the spec I am not clear
on whether the exception handling behaviour should be as I described when I
raised the issue.
The spec states:
{quote}
Valid parameter types for each of the above annotations are listed in the
corresponding Javadoc, however in general (excluding @Context) the following
types are supported:
1. Types for which a ParamConverter is available via a registered
ParamConverterProvider. See Javadoc for these classes for more information.
2. Primitive types.
3. Types that have a constructor that accepts a single String argument.
4. Types that have a static method named valueOf or fromString with a single
String argument that return an instance of the type. If both methods are
present then valueOf MUST be used unless the type is an enum in which case
fromString MUST be used.
5. List<T>, Set<T>, or SortedSet<T>, where T satisfies 3 or 4 above.
{quote}
followed by
{quote}
A WebApplicationException thrown during construction of field or property
values using 3 or 4 above is processed directly as described in Section 3.3.4.
Other exceptions thrown during construction of field or property values using 3
or 4 above are treated as client errors: if the field or property is annotated
with @MatrixParam, @QueryParam or @PathParam then an implementation MUST
generate an instance of NotFoundException (404 status) that wraps the thrown
exception and no entity; if the field or property is annotated with
@HeaderParam or @CookieParam then an implementation MUST generate an instance
of BadRequestException (400 status) that wraps the thrown exception and no
entity. Exceptions MUST be processed as described in Section 3.3.4.
{quote}
Strictly speaking, this does not state what should be done with exceptions from
ParamConverters, so the intended behaviour MAY have been to propagate the
exception as CXF does in 3.0.2.
This would however lead to different behaviour depending on which conversion
process was used for a particular parameter.
In theory the developer could add an ExceptionMapper for handling
IllegalArgumentExceptions, but it seems bad to assume that all
IllegalArgumentExceptions have been triggered due to a parameter conversion.
Could someone review this and clarify what the correct behaviour is?
> Exceptions thrown from ParamConverter generate 500 response
> -----------------------------------------------------------
>
> Key: CXF-6155
> URL: https://issues.apache.org/jira/browse/CXF-6155
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.0.2
> Reporter: Nigel Hannam
> Assignee: Sergey Beryozkin
> Fix For: 3.0.4, 3.1.0
>
>
> JAX-RS 2.0 (section 3.2) indicates that failure to convert a parameter value
> should trigger either a 404 or 400, and CXF does this correctly under some
> circumstances.
> When the conversion is performed using a ParamConverter (see
> InjectionUtils.handleParameter and it's call to
> InjectionUtils.createFromParameterHandler), any exception thrown by the
> ParamConverter is left unhandled and eventually triggers a 500 response.
> At the very least, any IllegalArgumentException from the ParamConverter
> should be caught and converted into the appropriate 400/404 error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
