[ 
https://issues.apache.org/jira/browse/WINK-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726657#action_12726657
 ] 

Jesse Ramos commented on WINK-36:
---------------------------------

On a related note, when a WebApplicationException is thrown when constructing 
field parameters, a 500 error is thrown.  Like before, in this case the 
WebApplicationException should get thrown and processed as is.

Furthermore, when an exception other than WebApplicationException is thrown, a 
400 or 404 (depending on the annotation) should be thrown, not 500.

In CreationUtils.createObject(ClassMetadata, RuntimeContext), the Exception is 
being caught and wrapped in an ObjectCreationException. In this particular 
case, the status code is automatically set to 500.

Not quite sure what the fix should be here since it seems the same code is run 
if there is an error creating instances of MessageBodyReaders and Writers.

I'll attach some unit tests that highlight the issues.

> WebApplicationException thrown in annotated parameter constructor not 
> processed correctly
> -----------------------------------------------------------------------------------------
>
>                 Key: WINK-36
>                 URL: https://issues.apache.org/jira/browse/WINK-36
>             Project: Wink
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 0.1
>            Reporter: Jesse Ramos
>            Priority: Minor
>
> When a method parameter is annotated, for example with @HeaderParam, if the 
> constructor of the field throws a WebApplicationException, the exception 
> should be processed directly according to section 3.2 of the spec. Currently, 
> it ends up being wrapped within another WebApplicationException and the 
> status code and entity are lost.
> Java throws an InvocationException which is caught in ValueConverter and 
> transformed into a ConversionException.  Within ServerInjectableFactory, the 
> ConversionException is then transformed into a WebApplicationException with 
> status code 400, which is what should happen for other types of Exceptions.
> The cause of the InvocationException needs to be examined.  If the cause is a 
> WebApplicationException, it needs to be rethrown instead of being transformed 
> into a ConversionException.
> Working on converting some integration tests that will expose the problem 
> which I'll drop in another bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to