Hi Ben,
I will revisit this at the start of next week and try and formalize the
issues more clearly.
It may be we have to have something specific in Jersey rather than
deferring to servlet. For example if the Jersey runtime has a status >=
400 look up an entity instance for that status code. It would also be
nice if we could get that working for the MVC stuff i plan to work on.
Should there be a per-resource class mapping or a per-web application
mapping, or both? I would be interested in hearing what people want in
this respect to help guide the solution.
Paul.
Ben wrote:
> Hi there,
>
> This was lying a while... I wonder if there are any plans to support such
> error page mappings with Jersey? My use-case is a mobile application so I do
> not want any uneccesary bytes transferred to the client, therefore custom
> error pages is a must.
>
> Best regards Ben
>
> -----Original Message-----
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Donnerstag, 17. Januar 2008 12:13
> To: users_at_jersey.dev.java.net; ben.mail_at_vtxfree.ch
> Subject: Re: Custom Errors and Glassfish
>
>
> Hi Ben
>
> ben.mail_at_vtxfree.ch wrote:
>> Related to :
>> _https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=390_
>> <https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=390>
>>
>
> Thanks for following up from the related message.
>
>
>> I am trying to map a error class / code to custom error page in my
> web.xml.
>> I am executing following method:
>>
>> @HttpMethod("POST")
>> @ConsumeMime({"application/xml", "application/json"})
>> public Response post( Foo data) {
>>
>> - Errors from the container like marshalling or basic auth exception do
>> get mapped
>> - Throwing programmatically a RuntimeException gets mapped
>>
>> - however when throwing: new
>>
> WebApplicationException(Response.Builder.serverError().status(403).build());
>
>> I get the standard glassfish error page (with the correct error) and the
>> mapping to my custom error page fails. Nothing in the server log
>> indicating a mapping error.
>>
>
> The Jersey runtime catches the WebApplicationException, so it is never
> propagated to the servlet container, and so it cannot be trapped by an
> error page.
>
> If WebApplicationException was re-thrown the status set by the Jersey
> servlet, from the info in WebApplicationException, would be ignored and
> would result in a 500 status code as far as i can tell.
>
> It appears error page support like the following:
>
> <error-page>
> <error-code>404</error-code>
> <location>/notFound.jsp</location>
> </error-page>
>
> only works if a request as not been dispatched to a servlet i.e. it does
> not appear to work when a request is dispatched to a servlet that sets
> the status code and returns without throwing an exception. So in that
> case i don't know how one can return a page for 415 (Unsupported Media
> Type).
>
> The same behavior occurs for Tomcat 6.0.14 and GF v2.
>
> I am not that familiar with this area of Web apps but anyway all this
> does indicate we need some improvements. Maybe we need something
> 311/Jersey specific for handling error pages?
>
>
>> I am using nb6, jersey 0.4, glassfishv2ur1.
>>
>> .
>> Side question, sorry if this is documented elsewhere: do you recommend
>> using jersey 0.5-ea instead of the latest 0.4 / differences?
>>
>
> A stable version of 0.5 ea will be out this Friday. I recommend you
> switch to that, although you will still observe the same error behavior
> as you observe for 0.4.
>
> Paul.
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109