On Thu, 23 Sep 2010 at 10:51:31 Paul Sandoz <Paul.Sandoz_at_oracle.com>
wrote:
>The @Produces annotation is only taken into account when the resource
>method is invoked and is not processed when a request filter is
>invoked that throws an exception to terminate the filter chain.
Ok.. seems odd though, If I use the wrong type I get an exception that it doesn't match - which is ok.
However given a list of choices it selects the first accept type provided by the client, similarly if a wildcard is in there it
always returns text/html, both of which seem odd.
>What type of exception are you throwing and are you using an ExceptionMapper?
I'm throwing one of my own exceptions based on RuntimeException although I think the same behaviour happens if I throw
one based on WebApplicationException. I am using an ExceptionMapper that correctly picks up the exception and if I throw the
exception in the resource method I get the correct behaviour.
Given you say that the produces type isn't used in filters, is it possible to determine what the method was annotated with in the filter and what
mediatype to use for the response?
Thanks
John
>On Sep 22, 2010, at 2:21 PM, John Lister wrote:
>> Hi, I have a resource filter which check some state to determine if
>> a request is authorised and if not throws an exception. This
>> exception (along with others) is caught in a custom mapper which
>> returns an error object wrapped in a response that depending upon
>> the accept type is rendered in various ways.
>
>> To determine if the checks are required I annotate either the class
>> or method with a custom annotation and use a resource filter factory
>> to apply the filter to every method tagged (or all if the class is
>> tagged).
>>
>> All seems to work well, except if I use @Produces on my methods and
>> have an accept type of */*.
>>
>> For example take the following:
>>
>> @Path("/test/")
>> @AuthorisedCheck
>> @Produces("application/xml")
>> public Response getTest(){....}
>>
>>
>> If I set the request header to application/xml, all goes to plan and
>> I get back an xml error when the checks fail. Using an explicit type
>> of text/html results in a 406 (Not acceptable) error as expected.
>> However there are 2 exceptions to this behaviour:
>> - if just */* is supplied as the accept type then html is returned
>> even though I would expect xml
>> - secondly if the list of types includes xml or a matching wildcard,
>> then the first type in the list is matched incorrectly. For example
>> text/html,application/xml would match and return html, again I
>> would expect xml to be returned?
>>
>> This would appear to be a bug in the filter exception handling, in
>> that if I don't use the filter and throw the exception directly from
>> the resource, the correct type is used.
> For additional commands, e-mail: users-help_at_jersey.dev.java.net