Skip to main content

JAX-RS error code 500 = GlassFish HTML error page

48 replies [Last post]
rdelaplante
Offline
Joined: 2007-04-01

Hi,

I'm creating a JAX-RS web service using Jersey in GlassFish 2.1. When my service returns error code 500 for server error, along with a "Reason-Phrase" response header, GlassFish completely takes over the response and outputs its own headers + body containing an HTML view of the error. I don't have any error pages configured in web.xml, this is a GlassFish branded error screen.

How can I tell GlassFish to leave my errors as-is so a REST client can make use of it?

How can I make GlassFish use custom error pages for all URI's that do not start with /rest/ ?

Thanks,
Ryan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Paul Sandoz

On Jan 15, 2010, at 7:26 PM, glassfish@javadesktop.org wrote:

> This sounds like a good idea. Sun should communicate this
> information to all other JAX-RS implementations so they can add the
> same GlassFish specific support. Too bad this behavior wasn't
> defined by the JAX-RS specification.

IIRC the source of the issue is different app servers have different
behavior for default error pages. Is default error page support
required by the servlet specification? If not then this requires some
clarification from the Servlet specfication before anything at the
level of JAX-RS can be specified.

Paul.

> Thanks,
> Ryan
>
>
>> I should mention that by having Jersey's
>> ServletContainerInitializer
>> set the new init parameter, no developer involvement
>> would be required,
>> that is, the web container's default error page would
>> be suppressed for any
>> JAX-RS requests out-of-the-box, which is what Markus
>> has been asking for.
>>
>>
>> Jan
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=381247
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/18/10 04:22 AM, Paul Sandoz wrote:
>
> On Jan 15, 2010, at 7:26 PM, glassfish@javadesktop.org wrote:
>
>> This sounds like a good idea. Sun should communicate this
>> information to all other JAX-RS implementations so they can add the
>> same GlassFish specific support. Too bad this behavior wasn't
>> defined by the JAX-RS specification.
>
> IIRC the source of the issue is different app servers have different
> behavior for default error pages. Is default error page support
> required by the servlet specification?

The default error page seems like a container implementation
detail. All that the Servlet spec requires is the following (see SRV
10.9.2: "Error Pages"):

If a servlet generates an error that is not handled by the error
page mechanism as described above, the container must ensure to
send a response with status 500.

Jan

> If not then this requires some clarification from the Servlet
> specfication before anything at the level of JAX-RS can be specified.
>
> Paul.
>
>> Thanks,
>> Ryan
>>
>>
>>> I should mention that by having Jersey's
>>> ServletContainerInitializer
>>> set the new init parameter, no developer involvement
>>> would be required,
>>> that is, the web container's default error page would
>>> be suppressed for any
>>> JAX-RS requests out-of-the-box, which is what Markus
>>> has been asking for.
>>>
>>>
>>> Jan
>> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=381247
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdelaplante
Offline
Joined: 2007-04-01

Thanks to everyone on the GlassFish and Jersey teams for taking this request seriously and implementing a solution so quickly!

I had a thought this morning. The @Produces annotation tells Jersey whether or not the response will be a web page. Maybe this annotation can somehow be used to tell the servlet container when to use or ignore web.xml defined error pages, based on MIME type. This would assume that web.xml error pages are always web pages.

Ryan

Markus Karg

Once more I want to mention that from the view of architecture and the WORA principle, this is not very smart: It enforces all JAX-RS implementations to learn about the particular GlassFish product. A good solution would be that a JAX-RS implementation doesn't have to know about GlassFish, but that GlassFish learns that a JAX-RS resource must not be fitted with an error page.

> -----Original Message-----
> From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
> Sent: Freitag, 15. Januar 2010 20:26
> To: users@glassfish.dev.java.net
> Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
>
> This sounds like a good idea. Sun should communicate this information
> to all other JAX-RS implementations so they can add the same GlassFish
> specific support. Too bad this behavior wasn't defined by the JAX-RS
> specification.
>
>
> Thanks,
> Ryan
>
>
> > I should mention that by having Jersey's
> > ServletContainerInitializer
> > set the new init parameter, no developer involvement
> > would be required,
> > that is, the web container's default error page would
> > be suppressed for any
> > JAX-RS requests out-of-the-box, which is what Markus
> > has been asking for.
> >
> >
> > Jan
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=381247
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 18, 2010, at 8:02 AM, Markus Karg wrote:

> Once more I want to mention that from the view of architecture and
> the WORA principle, this is not very smart: It enforces all JAX-RS
> implementations to learn about the particular GlassFish product. A
> good solution would be that a JAX-RS implementation doesn't have to
> know about GlassFish, but that GlassFish learns that a JAX-RS
> resource must not be fitted with an error page.

Either way it is gonna require some standardization in JAX-RS may
maybe servlet to make this portable.

Paul.

>
>> -----Original Message-----
>> From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
>> Sent: Freitag, 15. Januar 2010 20:26
>> To: users@glassfish.dev.java.net
>> Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
>>
>> This sounds like a good idea. Sun should communicate this
>> information
>> to all other JAX-RS implementations so they can add the same
>> GlassFish
>> specific support. Too bad this behavior wasn't defined by the JAX-
>> RS
>> specification.
>>
>>
>> Thanks,
>> Ryan
>>
>>
>>> I should mention that by having Jersey's
>>> ServletContainerInitializer
>>> set the new init parameter, no developer involvement
>>> would be required,
>>> that is, the web container's default error page would
>>> be suppressed for any
>>> JAX-RS requests out-of-the-box, which is what Markus
>>> has been asking for.
>>>
>>>
>>> Jan
>> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=381247
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 15, 2010, at 7:16 PM, Jan Luehe wrote:

> On 01/15/10 10:23 AM, Jan Luehe wrote:
>>
>> Paul,
>>
>> On 01/15/10 02:40 AM, Paul Sandoz wrote:
>>>
>>> On Jan 15, 2010, at 8:45 AM, Markus Karg wrote:
>>>
>>>> Sounds like a patch but not like a solution. People want out-of-
>>>> the-box Java EE correctness, not patches. At least me. ;-)
>>>>
>>>
>>> I think we are progressing to a good solution.
>>>
>>> Since, as i understand this, the default error page support is
>>> implementation specific feature then for Jersey we might be able
>>> to set a GF specific property on deployment via code. Jan, do you
>>> know if that would be possible per servlet?
>>
>> If we wanted to configure this on a per-servlet basis, one idea
>> would be to
>> leverage servlet init parameters.
>>
>> When Jersey's ServletContainerInitializer registers a Jersey
>> integration servlet,
>> it would also specify this init parameter.
>>
>> In case of an error, the web container could check if the target
>> servlet to which
>> the request was mapped was configured with this init parameter, and
>> disable
>> the default error page accordingly.
>>
>> This solution would not require any new property in sun-web.xml.
>>
>> What do you think?
>
> I should mention that by having Jersey's ServletContainerInitializer
> set the new init parameter, no developer involvement would be
> required,
> that is, the web container's default error page would be suppressed
> for any
> JAX-RS requests out-of-the-box, which is what Markus has been asking
> for.
>

+1

Paul.
[att1.html]

Markus Karg

Sounds like a patch but not like a solution. People want out-of-the-box Java EE correctness, not patches. At least me. ;-)

From: Jan.Luehe@Sun.COM [mailto:Jan.Luehe@Sun.COM]
Sent: Freitag, 15. Januar 2010 01:18
To: users@glassfish.dev.java.net
Subject: Re: JAX-RS error code 500 = GlassFish HTML error page

On 01/14/10 03:21 PM, glassfish@javadesktop.org wrote:

What about when I configure custom error pages for 404, 500, etc. because my .war file contains a website, but the JAX-RS API in the same .war file needs to return 404 and 500 error codes? The custom error page should not be sent in the JAX-RS API responses. I don't have a good solution to offer.

This goes back to your original question:

How can I make GlassFish use custom error pages for all URI's that
do not start with /rest/ ?

Perhaps the new configuration in sun-web.xml that will be used
to disable the default error page could specify a comma-separated
list of request url-patterns (path prefices) as its value. An empty list
would disable the default error page for the entire application.

Jan

I like your suggestion of allowing to disable the
default error page
on a per-application basis via some configuration in
sun-web.xml, and have
reopened
https://glassfish.dev.java.net/issues/show_bug.cgi?id=
11423
(the issue
that Ryan had filed) so that it can be fixed
accordingly.

Thanks,

Jan

[Message sent by forum member 'rdelaplante' (ryan@ijws.com)]

http://forums.java.net/jive/thread.jspa?messageID=381037

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

[att1.html]

Paul Sandoz

On Jan 15, 2010, at 8:45 AM, Markus Karg wrote:

> Sounds like a patch but not like a solution. People want out-of-the-
> box Java EE correctness, not patches. At least me. ;-)
>

I think we are progressing to a good solution.

Since, as i understand this, the default error page support is
implementation specific feature then for Jersey we might be able to
set a GF specific property on deployment via code. Jan, do you know if
that would be possible per servlet?

Paul.

>
> From: Jan.Luehe@Sun.COM [mailto:Jan.Luehe@Sun.COM]
> Sent: Freitag, 15. Januar 2010 01:18
> To: users@glassfish.dev.java.net
> Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
>
> On 01/14/10 03:21 PM, glassfish@javadesktop.org wrote:
> What about when I configure custom error pages for 404, 500, etc.
> because my .war file contains a website, but the JAX-RS API in the
> same .war file needs to return 404 and 500 error codes? The custom
> error page should not be sent in the JAX-RS API responses. I don't
> have a good solution to offer.
>
>
> This goes back to your original question:
>
> How can I make GlassFish use custom error pages for all URI's that
> do not start with /rest/ ?
>
> Perhaps the new configuration in sun-web.xml that will be used
> to disable the default error page could specify a comma-separated
> list of request url-patterns (path prefices) as its value. An empty
> list
> would disable the default error page for the entire application.
>
> Jan
>
>
>
>
>
>
>
> I like your suggestion of allowing to disable the
> default error page
> on a per-application basis via some configuration in
> sun-web.xml, and have
> reopened
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=
> 11423
> (the issue
> that Ryan had filed) so that it can be fixed
> accordingly.
>
> Thanks,
>
> Jan
>
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=381037
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

[att1.html]

Jan Luehe

Paul,

On 01/15/10 02:40 AM, Paul Sandoz wrote:
> On Jan 15, 2010, at 8:45 AM, Markus Karg wrote:
>
>> Sounds like a patch but not like a solution. People want
>> out-of-the-box Java EE correctness, not patches. At least me. ;-)
>>
>
> I think we are progressing to a good solution.
>
> Since, as i understand this, the default error page support is
> implementation specific feature then for Jersey we might be able to
> set a GF specific property on deployment via code. Jan, do you know if
> that would be possible per servlet?

If we wanted to configure this on a per-servlet basis, one idea would be to
leverage servlet init parameters.

When Jersey's ServletContainerInitializer registers a Jersey integration
servlet,
it would also specify this init parameter.

In case of an error, the web container could check if the target servlet
to which
the request was mapped was configured with this init parameter, and disable
the default error page accordingly.

This solution would not require any new property in sun-web.xml.

What do you think?

Jan

>
> Paul.
>
>>
>> *From:* Jan.Luehe@Sun.COM
>> [mailto:Jan.Luehe@Sun.COM]
>> *Sent:* Freitag, 15. Januar 2010 01:18
>> *To:* users@glassfish.dev.java.net
>> *Subject:* Re: JAX-RS error code 500 = GlassFish HTML error page
>>
>> On 01/14/10 03:21 PM, glassfish@javadesktop.org
>> wrote:
>> What about when I configure custom error pages for 404, 500, etc. because my .war file contains a website, but the JAX-RS API in the same .war file needs to return 404 and 500 error codes? The custom error page should not be sent in the JAX-RS API responses. I don't have a good solution to offer.
>>
>>
>> This goes back to your original question:
>>
>> How can I make GlassFish use custom error pages for all URI's that
>> do not start with /rest/ ?
>>
>> Perhaps the new configuration in sun-web.xml that will be used
>> to disable the default error page could specify a comma-separated
>> list of request url-patterns (path prefices) as its value. An empty list
>> would disable the default error page for the entire application.
>>
>> Jan
>>
>>
>>
>>
>>
>>
>>
>>
>> I like your suggestion of allowing to disable the
>>
>> default error page
>>
>> on a per-application basis via some configuration in
>>
>> sun-web.xml, and have
>>
>> reopened
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=
>>
>> 11423
>>
>> (the issue
>>
>> that Ryan had filed) so that it can be fixed
>>
>> accordingly.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Jan
>>
>>
>>
>> [Message sent by forum member 'rdelaplante' (ryan@ijws.com )]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=381037
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>>
>

[att1.html]

Jan Luehe

On 01/15/10 10:23 AM, Jan Luehe wrote:
> Paul,
>
> On 01/15/10 02:40 AM, Paul Sandoz wrote:
>> On Jan 15, 2010, at 8:45 AM, Markus Karg wrote:
>>
>>> Sounds like a patch but not like a solution. People want
>>> out-of-the-box Java EE correctness, not patches. At least me. ;-)
>>>
>>
>> I think we are progressing to a good solution.
>>
>> Since, as i understand this, the default error page support is
>> implementation specific feature then for Jersey we might be able to
>> set a GF specific property on deployment via code. Jan, do you know
>> if that would be possible per servlet?
>
> If we wanted to configure this on a per-servlet basis, one idea would
> be to
> leverage servlet init parameters.
>
> When Jersey's ServletContainerInitializer registers a Jersey
> integration servlet,
> it would also specify this init parameter.
>
> In case of an error, the web container could check if the target
> servlet to which
> the request was mapped was configured with this init parameter, and
> disable
> the default error page accordingly.
>
> This solution would not require any new property in sun-web.xml.
>
> What do you think?

I should mention that by having Jersey's ServletContainerInitializer
set the new init parameter, no developer involvement would be required,
that is, the web container's default error page would be suppressed for any
JAX-RS requests out-of-the-box, which is what Markus has been asking for.

Jan

>
> Jan
>
>>
>> Paul.
>>
>>>
>>> *From:* Jan.Luehe@Sun.COM
>>> [mailto:Jan.Luehe@Sun.COM]
>>> *Sent:* Freitag, 15. Januar 2010 01:18
>>> *To:* users@glassfish.dev.java.net
>>> *Subject:* Re: JAX-RS error code 500 = GlassFish HTML error page
>>>
>>> On 01/14/10 03:21 PM, glassfish@javadesktop.org
>>> wrote:
>>> What about when I configure custom error pages for 404, 500, etc. because my .war file contains a website, but the JAX-RS API in the same .war file needs to return 404 and 500 error codes? The custom error page should not be sent in the JAX-RS API responses. I don't have a good solution to offer.
>>>
>>>
>>> This goes back to your original question:
>>>
>>> How can I make GlassFish use custom error pages for all URI's that
>>> do not start with /rest/ ?
>>>
>>> Perhaps the new configuration in sun-web.xml that will be used
>>> to disable the default error page could specify a comma-separated
>>> list of request url-patterns (path prefices) as its value. An empty list
>>> would disable the default error page for the entire application.
>>>
>>> Jan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I like your suggestion of allowing to disable the
>>>
>>> default error page
>>>
>>> on a per-application basis via some configuration in
>>>
>>> sun-web.xml, and have
>>>
>>> reopened
>>>
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=
>>>
>>> 11423
>>>
>>> (the issue
>>>
>>> that Ryan had filed) so that it can be fixed
>>>
>>> accordingly.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Jan
>>>
>>>
>>>
>>> [Message sent by forum member 'rdelaplante' (ryan@ijws.com )]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=381037
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>>
>>>
>>
>

[att1.html]

rdelaplante
Offline
Joined: 2007-04-01

This sounds like a good idea. Sun should communicate this information to all other JAX-RS implementations so they can add the same GlassFish specific support. Too bad this behavior wasn't defined by the JAX-RS specification.

Thanks,
Ryan

> I should mention that by having Jersey's
> ServletContainerInitializer
> set the new init parameter, no developer involvement
> would be required,
> that is, the web container's default error page would
> be suppressed for any
> JAX-RS requests out-of-the-box, which is what Markus
> has been asking for.
>
>
> Jan

rdelaplante
Offline
Joined: 2007-04-01

Don't forget to make this work for the Filter way of configuring JAX-RS. When I use Jersey's servlet configuration, it doesn't handle any requests. Either that, or JSF stops working -- I forget. I had to use the Filter configuration instead.

In a Java EE 6 environment, how will JAX-RS/Jersey be configured? It will not be in my web.xml, but maybe GlassFish provides a default web-fragment.xml or default web.xml that contains the servlet or filter way of configuring Jersey? What if it uses the servlet way of doing it, then JSF web apps stop working? I didn't look deeper into the problem once I found that the filter configuration worked for me.

Thanks,
Ryan

> This sounds like a good idea. Sun should communicate
> this information to all other JAX-RS implementations
> so they can add the same GlassFish specific support.
> Too bad this behavior wasn't defined by the JAX-RS
> specification.
>
>
> Thanks,
> Ryan
>
>
> > I should mention that by having Jersey's
> > ServletContainerInitializer
> > set the new init parameter, no developer
> involvement
> > would be required,
> > that is, the web container's default error page
> would
> > be suppressed for any
> > JAX-RS requests out-of-the-box, which is what
> Markus
> > has been asking for.
> >
> >
> > Jan

Paul Sandoz

On Jan 15, 2010, at 7:41 PM, glassfish@javadesktop.org wrote:

> Don't forget to make this work for the Filter way of configuring JAX-
> RS. When I use Jersey's servlet configuration, it doesn't handle
> any requests. Either that, or JSF stops working -- I forget. I had
> to use the Filter configuration instead.
>

OK! The place where i can set this is in the abstraction that supports
Servlet and Filter config parameters through a common interface.

> In a Java EE 6 environment, how will JAX-RS/Jersey be configured?

Currently it is only using Servlet (not filter). There are two options:

1) define an annotation for use on javax.ws.rs.core.Applcation classes.

2) Jersey's implementation detects portable filter declarations in the
web.xml

Could you log an issue for the latter against Jersey as that is
certain something i can easily fix without introducing any new
interface.

> It will not be in my web.xml, but maybe GlassFish provides a
> default web-fragment.xml or default web.xml that contains the
> servlet or filter way of configuring Jersey? What if it uses the
> servlet way of doing it, then JSF web apps stop working?

I think it might also depend on the URL patterns that are utilized.

> I didn't look deeper into the problem once I found that the filter
> configuration worked for me.
>

OK.

Paul.

>
> Thanks,
> Ryan
>
>> This sounds like a good idea. Sun should communicate
>> this information to all other JAX-RS implementations
>> so they can add the same GlassFish specific support.
>> Too bad this behavior wasn't defined by the JAX-RS
>> specification.
>>
>>
>> Thanks,
>> Ryan
>>
>>
>>> I should mention that by having Jersey's
>>> ServletContainerInitializer
>>> set the new init parameter, no developer
>> involvement
>>> would be required,
>>> that is, the web container's default error page
>> would
>>> be suppressed for any
>>> JAX-RS requests out-of-the-box, which is what
>> Markus
>>> has been asking for.
>>>
>>>
>>> Jan
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=381250
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Markus Karg

Paul,

> The web tier team. However, i do not think it my call to dictate my

Ok, so will I do that for you instead. ;-)

> preference in this respect (assuming i am correct and the default
> behavior is not required by Servlet) as i understand disabling the
> feature by default will also cause complications for other users. So a
> good compromise would be to have a, documented, per-servlet/per-web-
> app init/context parameter.

As long as it implies that a pure Java EE RI download will be already
configured in that way, I don't have any problem with such a switch. I
only have a problem with the fact that some people started to discuss
the idea that the JAX-RS people must configure something to get GF run
the clean way.

Regards
Markus

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 13, 2010, at 11:16 PM, Jan Luehe wrote:

> On 01/13/10 01:22 PM, glassfish@javadesktop.org wrote:
>>
>>> Earlier in this thread, you mentioned a quote from
>>> the W3C
>>> specification for HTTP response codes in the 4xx and
>>> 5xx ranges:
>>>
>>> Except when responding to a HEAD request, the
>>> server SHOULD include
>>> an entity containing an explanation of the error
>>> situation.
>>> This is where the default error page comes into the
>>> picture.
>>>
>>> If you don't have any error pages configured for your
>>> app and want to
>>> bypass the default error page, you could do something
>>> like this in your
>>> servlet's service method:
>>>
>>> try {
>>> // some code here
>>> } catch (Throwable t) {
>>> response.setStatus(500);
>>> response.flushBuffer();
>>> // rethrow
>>> throw new ServletException(t);
>>> }
>>> ld that work for you?
>>>
>>
>>
>> I am not writing a servlet -- I am writing a JAX-RS service so that
>> does not work for me.
>>
>>
> I know, my comment was more targeted towards the Jersey integration
> servlet, and therefore Paul.
>
> I'm not familiar with any Jersey implementation details, but I suspect
> that when you output an entity body to the JAX-RS response (when
> returning an error), this will commit the corresponding HTTP response,
> and therefore, the web container's error page mechanism (and its
> default error page) will be completely bypassed, even if a matching
> error page
> existed. In other words, the GlassFish web container won't "take
> over the response",
> as you put it.
>

We have specified JAX-RS and carefully implemented Jersey such that if
one wants to map error-based status codes, when no response entity is
declared, or map exceptions passed from Jersey to the servlet layer
then it is possible i.e. it provides good integration with the servlet
layer.

The problem here is that GF is providing some defaults on behalf of
the developer when no response entity and error page mapping is
declared. IIRC App servers like WebSphere and WebLogic do not do this
by default?

Invariable any Web app deployed in production be it HTML based or
otherwise will likely want to override the default error page behavior
supplied by GF so I suspect the value for such default behavior is
when developing to aid the developer so they don't state bemused at an
empty page in the browser when a 404 or 500 status code is returned.

> If I understood your original request correctly, you wanted to be able
> to get the above behaviour (of GlassFish not interfering with your
> response) *without* having to provide an entity in the JAX-RS
> response.
>
> As I mentioned earlier, the Servlet spec requires that the web
> container use the sendError method to send 4xx and 5xx status
> responses, so that the error mechanism may be invoked.

Yes, but IIRC Servlet does not specify that default error pages should
be returned if the client does not declare error page mappings.

> sendError is
> required to clear the response buffer and return the contents of the
> error page. Note that the web container will *not* invoke sendError
> semantics if the response has already been committed.
>

If i write a simple servlet like the following it still returns a
default error page:

public class NewServlet extends HttpServlet {

@Override
public void service(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setStatus(500);
}
}

> So the trick is to ensure that the response has already been committed
> when it is returned through the web container. Apparently, outputting
> an entity to the JAX-RS response has this effect, but perhaps the
> Jersey integration servlet could commit (under the circumstances
> mentioned in this thread) the response even if no entity body has been
> written.
>

I disagree (see above). IMHO the correct approach is to ensure that
default error page support is switched off by default and may be
enabled per web application (or per servlet).

Paul.
[att1.html]

Jan Luehe

On 01/14/10 03:39 AM, Paul Sandoz wrote:
>
> On Jan 13, 2010, at 11:16 PM, Jan Luehe wrote:
>
>> On 01/13/10 01:22 PM, glassfish@javadesktop.org wrote:
>>>> Earlier in this thread, you mentioned a quote from
>>>> the W3C
>>>> specification for HTTP response codes in the 4xx and
>>>> 5xx ranges:
>>>>
>>>> Except when responding to a HEAD request, the
>>>> server SHOULD include
>>>> an entity containing an explanation of the error
>>>> situation.
>>>> This is where the default error page comes into the
>>>> picture.
>>>>
>>>> If you don't have any error pages configured for your
>>>> app and want to
>>>> bypass the default error page, you could do something
>>>> like this in your
>>>> servlet's service method:
>>>>
>>>> try {
>>>> // some code here
>>>> } catch (Throwable t) {
>>>> response.setStatus(500);
>>>> response.flushBuffer();
>>>> // rethrow
>>>> throw new ServletException(t);
>>>> }
>>>> ld that work for you?
>>>>
>>>
>>>
>>> I am not writing a servlet -- I am writing a JAX-RS service so that does not work for me.
>>>
>>>
>> I know, my comment was more targeted towards the Jersey integration
>> servlet, and therefore Paul.
>>
>> I'm not familiar with any Jersey implementation details, but I suspect
>> that when you output an entity body to the JAX-RS response (when
>> returning an error), this will commit the corresponding HTTP response,
>> and therefore, the web container's error page mechanism (and its
>> default error page) will be completely bypassed, even if a matching
>> error page
>> existed. In other words, the GlassFish web container won't "take over
>> the response",
>> as you put it.
>>
>
> We have specified JAX-RS and carefully implemented Jersey such that if
> one wants to map error-based status codes, when no response entity is
> declared, or map exceptions passed from Jersey to the servlet layer
> then it is possible i.e. it provides good integration with the servlet
> layer.
>
> The problem here is that GF is providing some defaults on behalf of
> the developer when no response entity and error page mapping is
> declared. IIRC App servers like WebSphere and WebLogic do not do this
> by default?
>
> Invariable any Web app deployed in production be it HTML based or
> otherwise will likely want to override the default error page behavior
> supplied by GF so I suspect the value for such default behavior is
> when developing to aid the developer so they don't state bemused at an
> empty page in the browser when a 404 or 500 status code is returned.
>
>
>> If I understood your original request correctly, you wanted to be able
>> to get the above behaviour (of GlassFish not interfering with your
>> response) *without* having to provide an entity in the JAX-RS response.
>>
>> As I mentioned earlier, the Servlet spec requires that the web
>> container use the sendError method to send 4xx and 5xx status
>> responses, so that the error mechanism may be invoked.
>
> Yes, but IIRC Servlet does not specify that default error pages should
> be returned if the client does not declare error page mappings.
>
>
>> sendError is
>> required to clear the response buffer and return the contents of the
>> error page. Note that the web container will *not* invoke sendError
>> semantics if the response has already been committed.
>>
>
> If i write a simple servlet like the following it still returns a
> default error page:
>
> public class NewServlet extends HttpServlet {
>
> @Override
> public void service(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException {
> response.setStatus(500);
> }
> }
>
>

This is indeed a bug. Calling HttpServletResponse#setStatus with an error
code correctly skips looking up any custom error pages, but still
includes the
default error page.

I've filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=11441 and
already fixed it.

I like your suggestion of allowing to disable the default error page
on a per-application basis via some configuration in sun-web.xml, and have
reopened https://glassfish.dev.java.net/issues/show_bug.cgi?id=11423
(the issue
that Ryan had filed) so that it can be fixed accordingly.

Thanks,

Jan

>
>> So the trick is to ensure that the response has already been committed
>> when it is returned through the web container. Apparently, outputting
>> an entity to the JAX-RS response has this effect, but perhaps the
>> Jersey integration servlet could commit (under the circumstances
>> mentioned in this thread) the response even if no entity body has been
>> written.
>>
>
> I disagree (see above). IMHO the correct approach is to ensure that
> default error page support is switched off by default and may be
> enabled per web application (or per servlet).
>
> Paul.

[att1.html]

rdelaplante
Offline
Joined: 2007-04-01

What about when I configure custom error pages for 404, 500, etc. because my .war file contains a website, but the JAX-RS API in the same .war file needs to return 404 and 500 error codes? The custom error page should not be sent in the JAX-RS API responses. I don't have a good solution to offer.

> I like your suggestion of allowing to disable the
> default error page
> on a per-application basis via some configuration in
> sun-web.xml, and have
> reopened
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=
> 11423
> (the issue
> that Ryan had filed) so that it can be fixed
> accordingly.
>
> Thanks,
>
> Jan

Jan Luehe

On 01/14/10 03:21 PM, glassfish@javadesktop.org wrote:
> What about when I configure custom error pages for 404, 500, etc. because my .war file contains a website, but the JAX-RS API in the same .war file needs to return 404 and 500 error codes? The custom error page should not be sent in the JAX-RS API responses. I don't have a good solution to offer.
>

This goes back to your original question:

How can I make GlassFish use custom error pages for all URI's that
do not start with /rest/ ?

Perhaps the new configuration in sun-web.xml that will be used
to disable the default error page could specify a comma-separated
list of request url-patterns (path prefices) as its value. An empty list
would disable the default error page for the entire application.

Jan

>
>
>
>> I like your suggestion of allowing to disable the
>> default error page
>> on a per-application basis via some configuration in
>> sun-web.xml, and have
>> reopened
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=
>> 11423
>> (the issue
>> that Ryan had filed) so that it can be fixed
>> accordingly.
>>
>> Thanks,
>>
>> Jan
>>
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=381037
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

rdelaplante
Offline
Joined: 2007-04-01

Yes that could work. I wonder how other application servers are dealing with this. It would be nice to find a solution that could one day make it into a Servlet and/or JAX-RS maintenance release so that we won't need to rely on proprietary deployment descriptors in the future.

> This goes back to your original question:
>
> How can I make GlassFish use custom error pages for
> all URI's that
> do not start with /rest/ ?
> Perhaps the new configuration in sun-web.xml that
> will be used
> to disable the default error page could specify a
> comma-separated
> list of request url-patterns (path prefices) as its
> value. An empty list
> would disable the default error page for the entire
> application.
>
> Jan
>

Markus Karg

I'd like to mention that GlassFish should be aware of the difference
between a JAX-RS response and a servlet response. Why? Because JAX-RS is
an API for writing *services* and the W3C just said *should* but not
*must*. So it should be up to the service author whether or not he
follows the W3C's wish. If the author thinks that it makes no sense to
have an error page, then none should get presented. This might be
different for a servlet, that mostly will return HTML to end users,
where virtually most authors don't care about whether there is an error
page contained or not. I mean, the JAX-RS team decided very carefully
and intentionally that a JAX-RS resource or engine is not mandatorily a
servlet. So GlassFish as the Java EE RI should understand that
difference and respect it. If the JAX-RS service authors want an error
page, they will provide one. If they don't want one, then they will
provide none. As a result, the only valid solution from the view of the
JAX-RS specification is that GlassFish must learn not to show an error
page. It is not Jersey's fault that one is shown, it is GlassFish's!

Regards

Markus

From: Jan.Luehe@Sun.COM [mailto:Jan.Luehe@Sun.COM]
Sent: Mittwoch, 13. Januar 2010 23:16
To: users@glassfish.dev.java.net
Subject: Re: JAX-RS error code 500 = GlassFish HTML error page

On 01/13/10 01:22 PM, glassfish@javadesktop.org wrote:

Earlier in this thread, you mentioned a quote from
the W3C
specification for HTTP response codes in the 4xx and
5xx ranges:

Except when responding to a HEAD request, the
server SHOULD include
an entity containing an explanation of the error
situation.
This is where the default error page comes into the
picture.

If you don't have any error pages configured for your
app and want to
bypass the default error page, you could do something
like this in your
servlet's service method:

try {
// some code here
} catch (Throwable t) {
response.setStatus(500);
response.flushBuffer();
// rethrow
throw new ServletException(t);
}
ld that work for you?

I am not writing a servlet -- I am writing a JAX-RS service so that does
not work for me.

I know, my comment was more targeted towards the Jersey integration
servlet, and therefore Paul.

I'm not familiar with any Jersey implementation details, but I suspect
that when you output an entity body to the JAX-RS response (when
returning an error), this will commit the corresponding HTTP response,
and therefore, the web container's error page mechanism (and its
default error page) will be completely bypassed, even if a matching
error page
existed. In other words, the GlassFish web container won't "take over
the response",
as you put it.

If I understood your original request correctly, you wanted to be able
to get the above behaviour (of GlassFish not interfering with your
response) *without* having to provide an entity in the JAX-RS response.

As I mentioned earlier, the Servlet spec requires that the web
container use the sendError method to send 4xx and 5xx status
responses, so that the error mechanism may be invoked. sendError is
required to clear the response buffer and return the contents of the
error page. Note that the web container will *not* invoke sendError
semantics if the response has already been committed.

So the trick is to ensure that the response has already been committed
when it is returned through the web container. Apparently, outputting
an entity to the JAX-RS response has this effect, but perhaps the
Jersey integration servlet could commit (under the circumstances
mentioned in this thread) the response even if no entity body has been
written.

Jan

However, if GlassFish is following the W3C and servlet specifications to
the letter, then I should be including an entity body whenever returning
an error status. When I return an entity body, GlassFish lets it
through. I think this morning I tested with error pages configured in
web.xml, and GlassFish allowed my response to be sent as-is to the
client even though an error page was defined for that error number.
That is what I want to happen. I suspect removing my entity body would
have caused GlassFish to display the appropriate error webpage.

Thanks,
Ryan
[Message sent by forum member 'rdelaplante' (ryan@ijws.com)]

http://forums.java.net/jive/thread.jspa?messageID=380759

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

[att1.html]

Paul Sandoz

On Jan 14, 2010, at 8:16 AM, Markus Karg wrote:

> I'd like to mention that GlassFish should be aware of the difference
> between a JAX-RS response and a servlet response. Why? Because JAX-
> RS is an API for writing *services*

No. JAX-RS can be used for writing RESTful Web applications serving
HTML, XML and JSON depending on what the client accepts (e.g. see the
RESTful admin support, or stuff what is being done in Apache Camel).
There is stuff in Jersey to enable just that (the MVC stuff).

I do not think this issue is specific to just JAX-RS/Jersey but to any
Servlet-based Web application. Invariably when one wants to deploy a
Web application in production then the default error pages will likely
be changed to something particular to the Web application. (And i do
see value in GF providing support for just that with customizable
themes.)

Paul.

> and the W3C just said *should* but not *must*. So it should be up to
> the service author whether or not he follows the W3C's wish. If the
> author thinks that it makes no sense to have an error page, then
> none should get presented. This might be different for a servlet,
> that mostly will return HTML to end users, where virtually most
> authors don't care about whether there is an error page contained or
> not. I mean, the JAX-RS team decided very carefully and
> intentionally that a JAX-RS resource or engine is not mandatorily a
> servlet. So GlassFish as the Java EE RI should understand that
> difference and respect it. If the JAX-RS service authors want an
> error page, they will provide one. If they don't want one, then they
> will provide none. As a result, the only valid solution from the
> view of the JAX-RS specification is that GlassFish must learn not to
> show an error page. It is not Jersey's fault that one is shown, it
> is GlassFish's!
>
> Regards
> Markus
>
>
> From: Jan.Luehe@Sun.COM [mailto:Jan.Luehe@Sun.COM]
> Sent: Mittwoch, 13. Januar 2010 23:16
> To: users@glassfish.dev.java.net
> Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
>
> On 01/13/10 01:22 PM, glassfish@javadesktop.org wrote:
> Earlier in this thread, you mentioned a quote from
> the W3C
> specification for HTTP response codes in the 4xx and
> 5xx ranges:
>
> Except when responding to a HEAD request, the
> server SHOULD include
> an entity containing an explanation of the error
> situation.
> This is where the default error page comes into the
> picture.
>
> If you don't have any error pages configured for your
> app and want to
> bypass the default error page, you could do something
> like this in your
> servlet's service method:
>
> try {
> // some code here
> } catch (Throwable t) {
> response.setStatus(500);
> response.flushBuffer();
> // rethrow
> throw new ServletException(t);
> }
> ld that work for you?
>
>
>
> I am not writing a servlet -- I am writing a JAX-RS service so that
> does not work for me.
>
>
> I know, my comment was more targeted towards the Jersey integration
> servlet, and therefore Paul.
>
> I'm not familiar with any Jersey implementation details, but I suspect
> that when you output an entity body to the JAX-RS response (when
> returning an error), this will commit the corresponding HTTP response,
> and therefore, the web container's error page mechanism (and its
> default error page) will be completely bypassed, even if a matching
> error page
> existed. In other words, the GlassFish web container won't "take
> over the response",
> as you put it.
>
> If I understood your original request correctly, you wanted to be able
> to get the above behaviour (of GlassFish not interfering with your
> response) *without* having to provide an entity in the JAX-RS
> response.
>
> As I mentioned earlier, the Servlet spec requires that the web
> container use the sendError method to send 4xx and 5xx status
> responses, so that the error mechanism may be invoked. sendError is
> required to clear the response buffer and return the contents of the
> error page. Note that the web container will *not* invoke sendError
> semantics if the response has already been committed.
>
> So the trick is to ensure that the response has already been committed
> when it is returned through the web container. Apparently, outputting
> an entity to the JAX-RS response has this effect, but perhaps the
> Jersey integration servlet could commit (under the circumstances
> mentioned in this thread) the response even if no entity body has been
> written.
>
>
> Jan
>
>
> However, if GlassFish is following the W3C and servlet
> specifications to the letter, then I should be including an entity
> body whenever returning an error status. When I return an entity
> body, GlassFish lets it through. I think this morning I tested with
> error pages configured in web.xml, and GlassFish allowed my response
> to be sent as-is to the client even though an error page was defined
> for that error number. That is what I want to happen. I suspect
> removing my entity body would have caused GlassFish to display the
> appropriate error webpage.
>
>
> Thanks,
> Ryan
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=380759
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

[att1.html]

Markus Karg

Paul,

actually I do not understand your beginning "No." -- you just repeated
the same idea that I posted: That it is not Jersey's fault but
GlassFish's! Maybe you misunderstood my posting? I explicitly wanted to
say that GlassFish shall abstain from mixing in any ideas into JAX-RS's
way, being error pages or anything else. Just what you also wrote in
your second paragraph.

Regards

Markus

From: Paul.Sandoz@Sun.COM [mailto:Paul.Sandoz@Sun.COM]
Sent: Donnerstag, 14. Januar 2010 12:52
To: users@glassfish.dev.java.net
Subject: Re: JAX-RS error code 500 = GlassFish HTML error page

On Jan 14, 2010, at 8:16 AM, Markus Karg wrote:

I'd like to mention that GlassFish should be aware of the difference
between a JAX-RS response and a servlet response. Why? Because JAX-RS is
an API for writing *services*

No. JAX-RS can be used for writing RESTful Web applications serving
HTML, XML and JSON depending on what the client accepts (e.g. see the
RESTful admin support, or stuff what is being done in Apache Camel).
There is stuff in Jersey to enable just that (the MVC stuff).

I do not think this issue is specific to just JAX-RS/Jersey but to any
Servlet-based Web application. Invariably when one wants to deploy a Web
application in production then the default error pages will likely be
changed to something particular to the Web application. (And i do see
value in GF providing support for just that with customizable themes.)

Paul.

[att1.html]

Paul Sandoz

Hi Markus,

I think default error page support should be disabled by default for
*any* deployed servlet and there is no need to distinguish between JAX-
RS and Servlet deployments in this case.

On Jan 14, 2010, at 1:34 PM, Markus Karg wrote:

> Paul,
>
> actually I do not understand your beginning "No." -- you just
> repeated the same idea that I posted:

Not quite. I do not agree with the following:

GlassFish should be aware of the difference between a JAX-RS
response and a servlet response

you can write a RESTful Web *service* using Servlet (or using a
framework layering on top of Servlet) and you can write a RESTful Web
*application* using JAX-RS (which layers on top of servlet for GF
deployments).

For some *service* is often used to categorize an API that produces/
consumes say JSON/XML and *application* is often used to categorize a
browser-based application. I personally do not see the need for such a
distinction from a REST perspective.

> That it is not Jersey's fault but GlassFish's! Maybe you
> misunderstood my posting?

No. I agree this is a GlassFish issue.

> I explicitly wanted to say that GlassFish shall abstain from mixing
> in any ideas into JAX-RS's way, being error pages or anything else.
> Just what you also wrote in your second paragraph.
>

I stated:

I do not think this issue is specific to just JAX-RS/Jersey but to
any servlet-based Web application.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Markus Karg

> I think default error page support should be disabled by default for
> *any* deployed servlet and there is no need to distinguish between
JAX-
> RS and Servlet deployments in this case.

I understand. No problem with that. I just didn't want to make any
restrictions to Servlets as I am only interested in JAX-RS and don't
know the actual content of the Servlet specification on this issue. :-)

> No. I agree this is a GlassFish issue.

Great! Who's in charge of fixing that? ;-)

> I do not think this issue is specific to just JAX-RS/Jersey but to
> any servlet-based Web application.

Have overseen that. Sorry.

Regards
Markus

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 14, 2010, at 3:16 PM, Markus Karg wrote:

>> I think default error page support should be disabled by default for
>> *any* deployed servlet and there is no need to distinguish between
> JAX-
>> RS and Servlet deployments in this case.
>
> I understand. No problem with that. I just didn't want to make any
> restrictions to Servlets as I am only interested in JAX-RS and don't
> know the actual content of the Servlet specification on this
> issue. :-)
>
>> No. I agree this is a GlassFish issue.
>
> Great! Who's in charge of fixing that? ;-)
>

The web tier team. However, i do not think it my call to dictate my
preference in this respect (assuming i am correct and the default
behavior is not required by Servlet) as i understand disabling the
feature by default will also cause complications for other users. So a
good compromise would be to have a, documented, per-servlet/per-web-
app init/context parameter.

IMHO the issue should be re-opened and clarified in this regard.

Paul.

>> I do not think this issue is specific to just JAX-RS/Jersey but to
>> any servlet-based Web application.
>
> Have overseen that. Sorry.
>
> Regards
> Markus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 14, 2010, at 3:37 PM, Paul Sandoz wrote:

>
> On Jan 14, 2010, at 3:16 PM, Markus Karg wrote:
>
>>> I think default error page support should be disabled by default for
>>> *any* deployed servlet and there is no need to distinguish between
>> JAX-
>>> RS and Servlet deployments in this case.
>>
>> I understand. No problem with that. I just didn't want to make any
>> restrictions to Servlets as I am only interested in JAX-RS and don't
>> know the actual content of the Servlet specification on this
>> issue. :-)
>>
>>> No. I agree this is a GlassFish issue.
>>
>> Great! Who's in charge of fixing that? ;-)
>>
>
> The web tier team. However, i do not think it my call to dictate my
> preference in this respect (assuming i am correct and the default
> behavior is not required by Servlet) as i understand disabling the
> feature by default will also cause complications for other users. So
> a good compromise would be to have a, documented, per-servlet/per-
> web-app init/context parameter.
>

Or something in the sun-web.xml.

Paul.

> IMHO the issue should be re-opened and clarified in this regard.
>
> Paul.
>
>>> I do not think this issue is specific to just JAX-RS/Jersey but to
>>> any servlet-based Web application.
>>
>> Have overseen that. Sorry.
>>
>> Regards
>> Markus
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/12/10 08:47 AM, Paul Sandoz wrote:
>
> On Jan 12, 2010, at 5:30 PM, glassfish@javadesktop.org wrote:
>
>> Well, GlassFish has sure made it difficult for me until I figured out
>> a work around. I am using GlassFish 2.1 which was not designed with
>> JAX-RS in mind. Maybe GlassFish V3 is aware of this issue and does
>> not interfere with JAX-RS error responses.
>>
>
> Unfortunately not. Basically a JAX-RS application is deployed as a
> servlet so the behavior is the same as any deployed servlet.
>
> I recommend logging a bug against GF stating that default error pages
> should be disabled (or as a compromise a feature is supported to
> disable default error pages).

You can disable the default error page by adding this property to the
virtual-server of your choice:

This property is already supported in v2.1.1 (and I believe v2.1 as well).

This setting would disable the default error page for all applications
deployed
on the particular virtual-server.

Would this satisfy Ryan's requirement?

Jan

>
> Paul.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 12, 2010, at 7:38 PM, Jan Luehe wrote:

> On 01/12/10 08:47 AM, Paul Sandoz wrote:
>>
>> On Jan 12, 2010, at 5:30 PM, glassfish@javadesktop.org wrote:
>>
>>> Well, GlassFish has sure made it difficult for me until I figured
>>> out a work around. I am using GlassFish 2.1 which was not
>>> designed with JAX-RS in mind. Maybe GlassFish V3 is aware of this
>>> issue and does not interfere with JAX-RS error responses.
>>>
>>
>> Unfortunately not. Basically a JAX-RS application is deployed as a
>> servlet so the behavior is the same as any deployed servlet.
>>
>> I recommend logging a bug against GF stating that default error
>> pages should be disabled (or as a compromise a feature is supported
>> to disable default error pages).
>
> You can disable the default error page by adding this property to the
> virtual-server of your choice:
>
>
>
> This property is already supported in v2.1.1 (and I believe v2.1 as
> well).
>

Great! Is there somewhere where all such properties are documented?

Paul.

> This setting would disable the default error page for all
> applications deployed
> on the particular virtual-server.
>
> Would this satisfy Ryan's requirement?
>
>
> Jan
>
>>
>> Paul.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/12/10 11:30 AM, Paul Sandoz wrote:
>
> On Jan 12, 2010, at 7:38 PM, Jan Luehe wrote:
>
>> On 01/12/10 08:47 AM, Paul Sandoz wrote:
>>>
>>> On Jan 12, 2010, at 5:30 PM, glassfish@javadesktop.org wrote:
>>>
>>>> Well, GlassFish has sure made it difficult for me until I figured
>>>> out a work around. I am using GlassFish 2.1 which was not designed
>>>> with JAX-RS in mind. Maybe GlassFish V3 is aware of this issue and
>>>> does not interfere with JAX-RS error responses.
>>>>
>>>
>>> Unfortunately not. Basically a JAX-RS application is deployed as a
>>> servlet so the behavior is the same as any deployed servlet.
>>>
>>> I recommend logging a bug against GF stating that default error
>>> pages should be disabled (or as a compromise a feature is supported
>>> to disable default error pages).
>>
>> You can disable the default error page by adding this property to the
>> virtual-server of your choice:
>>
>>
>>
>> This property is already supported in v2.1.1 (and I believe v2.1 as
>> well).
>>
>
> Great! Is there somewhere where all such properties are documented?

Unfortunately, the "errorReportValve" property is not documented.

I did some research and found that I had added this property in order
to address

https://glassfish.dev.java.net/issues/show_bug.cgi?id=7418
("Nead easy way to produce error responses with "text/xml" content type")

whose requirements I had summarized in the issue's Description section
as follows:

Need a way to disable the container's default error handling mechanism
for responses.

which is exactly what Ryan needs. :)

According to IT 7418, I added support for this property to v3
and backported it to v2.1.1 (meaning it's not available in v2.1).

I'll go ahead and close Ryan's ticket as a duplicate of the above issue, and
will open a new ticket (against docs) to have this property documented.

Thanks,

Jan

>
> Paul.
>
>
>> This setting would disable the default error page for all
>> applications deployed
>> on the particular virtual-server.
>>
>> Would this satisfy Ryan's requirement?
>>
>>
>> Jan
>>
>>>
>>> Paul.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jan Luehe

On 01/12/10 12:51 PM, Jan Luehe wrote:
> On 01/12/10 11:30 AM, Paul Sandoz wrote:
>>
>> On Jan 12, 2010, at 7:38 PM, Jan Luehe wrote:
>>
>>> On 01/12/10 08:47 AM, Paul Sandoz wrote:
>>>>
>>>> On Jan 12, 2010, at 5:30 PM, glassfish@javadesktop.org wrote:
>>>>
>>>>> Well, GlassFish has sure made it difficult for me until I figured
>>>>> out a work around. I am using GlassFish 2.1 which was not
>>>>> designed with JAX-RS in mind. Maybe GlassFish V3 is aware of this
>>>>> issue and does not interfere with JAX-RS error responses.
>>>>>
>>>>
>>>> Unfortunately not. Basically a JAX-RS application is deployed as a
>>>> servlet so the behavior is the same as any deployed servlet.
>>>>
>>>> I recommend logging a bug against GF stating that default error
>>>> pages should be disabled (or as a compromise a feature is supported
>>>> to disable default error pages).
>>>
>>> You can disable the default error page by adding this property to the
>>> virtual-server of your choice:
>>>
>>>
>>>
>>> This property is already supported in v2.1.1 (and I believe v2.1 as
>>> well).
>>>
>>
>> Great! Is there somewhere where all such properties are documented?
>
> Unfortunately, the "errorReportValve" property is not documented.
>
> I did some research and found that I had added this property in order
> to address
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=7418
> ("Nead easy way to produce error responses with "text/xml" content
> type")
>
> whose requirements I had summarized in the issue's Description section
> as follows:
>
> Need a way to disable the container's default error handling mechanism
> for responses.
>
> which is exactly what Ryan needs. :)
>
> According to IT 7418, I added support for this property to v3
> and backported it to v2.1.1 (meaning it's not available in v2.1).
>
> I'll go ahead and close Ryan's ticket as a duplicate of the above
> issue, and
> will open a new ticket (against docs) to have this property documented.

FYI, just filed this ticket against docs:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11426
("Add documentation for "errorReportValve" virtual server property")

Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 12, 2010, at 4:57 PM, Markus Karg wrote:

> So is that a bug in GF or is it not?
>

Well... i think it is, but i have discussed this before with the Web
tier developers and this behavior has been around a while so it is has
sort of become a feature that if removed may also cause frustration.

IMHO i think there should be a feature that can be enabled to turn off
such default error pages.

Paul.

>>> In my message above, I talked about application defined error pages,
>>> the same thing you mentioned here. My message is about creating a
>>> REST web service that returns an error as part of the API, and not
>>> wanting GlassFish to do anything but pass it to the client as-is. I
>>> don't want to return a web page.
>>
>>> I want to return exactly what my programming told GlassFish to
>>> return, so defining error-pages in web.xml completely defeats the
>>> purpose.
>>
>> Agreed, it was a suggestion to workaround GF restrictions.
>>
>> Paul.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Markus Karg

> -----Original Message-----
> From: Paul.Sandoz@Sun.COM [mailto:Paul.Sandoz@Sun.COM]
> Sent: Dienstag, 12. Januar 2010 17:27
> To: users@glassfish.dev.java.net
> Subject: Re: JAX-RS error code 500 = GlassFish HTML error page
>
>
> On Jan 12, 2010, at 4:57 PM, Markus Karg wrote:
>
> > So is that a bug in GF or is it not?
> >
>
> Well... i think it is, but i have discussed this before with the Web
> tier developers and this behavior has been around a while so it is has
> sort of become a feature that if removed may also cause frustration.
>
> IMHO i think there should be a feature that can be enabled to turn off
> such default error pages.
>
> Paul.

The old story... when does the GF team finally understand that it is
needed to cut off support for those pseudo-features with major GF
releases? I mean, it can't be true that one install the Java EE 6 RI and
first he has to do is to switch off things preventing to act like a
clean Java EE 6 RI. This is ridiculous. If some people like those
derivations from the spec, then pack all of them in a special legacy
profile which *those* people have to explicitly switch *on*... angry/>

Regards
Markus

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdelaplante
Offline
Joined: 2007-04-01

In the ticket I created, I suggested that GlassFish continue to display error pages (defined in web.xml, or the defaults), except when the response is sent by a JAX-RS resource. That's how it should be. Right now I have to disable my error pages, so if users try to access a web page that does not exist they will not see a pretty 404 error. I had to do that so the JAX-RS API would be usable. So, I don't think my ticket should have been closed, or at least it should have been changed to an RFE.

> The old story... when does the GF team finally
> understand that it is
> needed to cut off support for those pseudo-features
> with major GF
> releases? I mean, it can't be true that one install
> the Java EE 6 RI and
> first he has to do is to switch off things preventing
> to act like a
> clean Java EE 6 RI. This is ridiculous. If some
> people like those
> derivations from the spec, then pack all of them in a
> special legacy
> profile which *those* people have to explicitly
> switch *on*... > angry/>
>
> Regards
> Markus
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail:
> users-help@glassfish.dev.java.net

Jan Luehe

Ryan,

On 01/13/10 08:19 AM, glassfish@javadesktop.org wrote:
> In the ticket I created, I suggested that GlassFish continue to display error pages (defined in web.xml, or the defaults), except when the response is sent by a JAX-RS resource. That's how it should be. Right now I have to disable my error pages, so if users try to access a web page that does not exist they will not see a pretty 404 error. I had to do that so the JAX-RS API would be usable. So, I don't think my ticket should have been closed, or at least it should have been changed to an RFE.
>

I mentioned the "errorReportValve" property as a way to customize or
completely disable the default error page for a given virtual-server
(and all the applications deployed to it).

The Servlet spec (Section SRV 10.9.2: "Error Pages") has this:

The default servlet and container will use the sendError method to
send 4xx and 5xx status responses, so that the error mechanism may be
invoked.

This means that if your Servlet throws an exception, the error
mechanism will be invoked, which attempts to map the status code or
exception type to an error page declared in the deployment descriptor.

Earlier in this thread, you mentioned a quote from the W3C
specification for HTTP response codes in the 4xx and 5xx ranges:

Except when responding to a HEAD request, the server SHOULD include
an entity containing an explanation of the error situation.

This is where the default error page comes into the picture.

If you don't have any error pages configured for your app and want to
bypass the default error page, you could do something like this in your
servlet's service method:

try {
// some code here
} catch (Throwable t) {
response.setStatus(500);
response.flushBuffer();
// rethrow
throw new ServletException(t);
}

Would that work for you?

Jan

>
>
>
>> The old story... when does the GF team finally
>> understand that it is
>> needed to cut off support for those pseudo-features
>> with major GF
>> releases? I mean, it can't be true that one install
>> the Java EE 6 RI and
>> first he has to do is to switch off things preventing
>> to act like a
>> clean Java EE 6 RI. This is ridiculous. If some
>> people like those
>> derivations from the spec, then pack all of them in a
>> special legacy
>> profile which *those* people have to explicitly
>> switch *on*... >> angry/>
>>
>> Regards
>> Markus
>>
>> ------------------------------------------------------
>> ---------------
>> To unsubscribe, e-mail:
>> users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail:
>> users-help@glassfish.dev.java.net
>>
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=380677
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

rdelaplante
Offline
Joined: 2007-04-01

> Earlier in this thread, you mentioned a quote from
> the W3C
> specification for HTTP response codes in the 4xx and
> 5xx ranges:
>
> Except when responding to a HEAD request, the
> server SHOULD include
> an entity containing an explanation of the error
> situation.
> This is where the default error page comes into the
> picture.
>
> If you don't have any error pages configured for your
> app and want to
> bypass the default error page, you could do something
> like this in your
> servlet's service method:
>
> try {
> // some code here
> } catch (Throwable t) {
> response.setStatus(500);
> response.flushBuffer();
> // rethrow
> throw new ServletException(t);
> }
> ld that work for you?

I am not writing a servlet -- I am writing a JAX-RS service so that does not work for me.

However, if GlassFish is following the W3C and servlet specifications to the letter, then I should be including an entity body whenever returning an error status. When I return an entity body, GlassFish lets it through. I think this morning I tested with error pages configured in web.xml, and GlassFish allowed my response to be sent as-is to the client even though an error page was defined for that error number. That is what I want to happen. I suspect removing my entity body would have caused GlassFish to display the appropriate error webpage.

Thanks,
Ryan

Jan Luehe

On 01/13/10 01:22 PM, glassfish@javadesktop.org wrote:
>> Earlier in this thread, you mentioned a quote from
>> the W3C
>> specification for HTTP response codes in the 4xx and
>> 5xx ranges:
>>
>> Except when responding to a HEAD request, the
>> server SHOULD include
>> an entity containing an explanation of the error
>> situation.
>> This is where the default error page comes into the
>> picture.
>>
>> If you don't have any error pages configured for your
>> app and want to
>> bypass the default error page, you could do something
>> like this in your
>> servlet's service method:
>>
>> try {
>> // some code here
>> } catch (Throwable t) {
>> response.setStatus(500);
>> response.flushBuffer();
>> // rethrow
>> throw new ServletException(t);
>> }
>> ld that work for you?
>>
>
>
> I am not writing a servlet -- I am writing a JAX-RS service so that does not work for me.
>
>
I know, my comment was more targeted towards the Jersey integration
servlet, and therefore Paul.

I'm not familiar with any Jersey implementation details, but I suspect
that when you output an entity body to the JAX-RS response (when
returning an error), this will commit the corresponding HTTP response,
and therefore, the web container's error page mechanism (and its
default error page) will be completely bypassed, even if a matching
error page
existed. In other words, the GlassFish web container won't "take over
the response",
as you put it.

If I understood your original request correctly, you wanted to be able
to get the above behaviour (of GlassFish not interfering with your
response) *without* having to provide an entity in the JAX-RS response.

As I mentioned earlier, the Servlet spec requires that the web
container use the sendError method to send 4xx and 5xx status
responses, so that the error mechanism may be invoked. sendError is
required to clear the response buffer and return the contents of the
error page. Note that the web container will *not* invoke sendError
semantics if the response has already been committed.

So the trick is to ensure that the response has already been committed
when it is returned through the web container. Apparently, outputting
an entity to the JAX-RS response has this effect, but perhaps the
Jersey integration servlet could commit (under the circumstances
mentioned in this thread) the response even if no entity body has been
written.

Jan

> However, if GlassFish is following the W3C and servlet specifications to the letter, then I should be including an entity body whenever returning an error status. When I return an entity body, GlassFish lets it through. I think this morning I tested with error pages configured in web.xml, and GlassFish allowed my response to be sent as-is to the client even though an error page was defined for that error number. That is what I want to happen. I suspect removing my entity body would have caused GlassFish to display the appropriate error webpage.
>
>
> Thanks,
> Ryan
> [Message sent by forum member 'rdelaplante' (ryan@ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=380759
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

[att1.html]

rdelaplante
Offline
Joined: 2007-04-01

> > I am not writing a servlet -- I am writing a JAX-RS
> service so that does not work for me.
> >
> >
> I know, my comment was more targeted towards the
> Jersey integration
> servlet, and therefore Paul.

Ooops, I didn't realize that.

> If I understood your original request correctly, you
> wanted to be able
> to get the above behaviour (of GlassFish not
> interfering with your
> response) *without* having to provide an entity in
> the JAX-RS response.

Exactly! There are many scenarios where I don't need to send an entity in the response. The headers provide everything necessary. For now I'm resorting to sending something like "" as the body.

> perhaps the
> Jersey integration servlet could commit (under the
> circumstances
> mentioned in this thread) the response even if no
> entity body has been
> written.

I have to use the Jersey filter. If I use the Jersey servlet, then it either does not respond to any request, or it makes my JSF web app not work. I think the Jersey Filter and Jersey servlet are implemented in the same class.

Thanks,
Ryan

Paul Sandoz

On Jan 12, 2010, at 3:25 PM, glassfish@javadesktop.org wrote:

>> Check out the javax.ws.rs.ext.ExceptionMapper
>> interface.
>
> Thank you. I spent some time looking at this interface and don't
> think it will change anything for me. It looks like I would create
> an exception mapper if I wanted JAX-RS to know about an existing
> exception in my application. I am throwing an exception that
> extends WebApplicationException, and the constructor does the same
> thing as the example code in the Jersey documentation.
>

I think an ExceptionMapper might be an acceptable workaround. It is
possible to support an ExceptionMapper for WebApplication and in that
mapper you could add an entity, if one is not present, e.g. a String
with one space character.

> I don't think the problem is Jersey or JAX-RS. I think when
> GlassFish sees an application returning an HTTP error code, it first
> looks to see if the application has defined error pages to display.
> If not, then it displays its own error pages. This is undesirable
> for REST APIs since it totally rewrites the headers and body. The
> only way I could find to get around it is to make sure I output an
> entity body when returning an error. Then GlassFish seems to let it
> through.
>

Another solution is to add error pages to the web.xml:

http://java.sun.com/developer/EJTechTips/2003/tt0114.html

But ideally an option to switch off such default page support would be
most useful.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdelaplante
Offline
Joined: 2007-04-01

>
> On Jan 12, 2010, at 3:25 PM,
> glassfish@javadesktop.org wrote:
>
> >> Check out the javax.ws.rs.ext.ExceptionMapper
> >> interface.
> >
> > Thank you. I spent some time looking at this
> interface and don't
> > think it will change anything for me. It looks
> like I would create
> > an exception mapper if I wanted JAX-RS to know
> about an existing
> > exception in my application. I am throwing an
> exception that
> > extends WebApplicationException, and the
> constructor does the same
> > thing as the example code in the Jersey
> documentation.
> >
>
> I think an ExceptionMapper might be an acceptable
> workaround. It is
> possible to support an ExceptionMapper for
> WebApplication and in that
> mapper you could add an entity, if one is not
> present, e.g. a String
> with one space character.

I still don't understand how this will be different than extending WebApplicationException, which is part of JAX-RS and lets me provide the Response object in the constructor.

> > I don't think the problem is Jersey or JAX-RS. I
> think when
> > GlassFish sees an application returning an HTTP
> error code, it first
> > looks to see if the application has defined error
> pages to display.
> > If not, then it displays its own error pages. This
> is undesirable
> > for REST APIs since it totally rewrites the headers
> and body. The
> > only way I could find to get around it is to make
> sure I output an
> > entity body when returning an error. Then
> GlassFish seems to let it
> > through.
> >
>
> Another solution is to add error pages to the
> web.xml:
>
>
> ttp://java.sun.com/developer/EJTechTips/2003/tt0114.ht
> ml
>
> But ideally an option to switch off such default page
> support would be
> most useful.

In my message above, I talked about application defined error pages, the same thing you mentioned here. My message is about creating a REST web service that returns an error as part of the API, and not wanting GlassFish to do anything but pass it to the client as-is. I don't want to return a web page. I want to return exactly what my programming told GlassFish to return, so defining error-pages in web.xml completely defeats the purpose.

Paul Sandoz

On Jan 12, 2010, at 4:10 PM, glassfish@javadesktop.org wrote:

>>
>> On Jan 12, 2010, at 3:25 PM,
>> glassfish@javadesktop.org wrote:
>>
>>>> Check out the javax.ws.rs.ext.ExceptionMapper
>>>> interface.
>>>
>>> Thank you. I spent some time looking at this
>> interface and don't
>>> think it will change anything for me. It looks
>> like I would create
>>> an exception mapper if I wanted JAX-RS to know
>> about an existing
>>> exception in my application. I am throwing an
>> exception that
>>> extends WebApplicationException, and the
>> constructor does the same
>>> thing as the example code in the Jersey
>> documentation.
>>>
>>
>> I think an ExceptionMapper might be an acceptable
>> workaround. It is
>> possible to support an ExceptionMapper for
>> WebApplication and in that
>> mapper you could add an entity, if one is not
>> present, e.g. a String
>> with one space character.
>
> I still don't understand how this will be different than extending
> WebApplicationException, which is part of JAX-RS and lets me provide
> the Response object in the constructor.
>

There might be cases where WebApplicationException is thrown directly
or from extending classes e.g. by the runtime. Having an
ExceptionMapper operating on WebApplicationException allows you to
catch all cases (for which there is sub-classes mapped).

>
>>> I don't think the problem is Jersey or JAX-RS. I
>> think when
>>> GlassFish sees an application returning an HTTP
>> error code, it first
>>> looks to see if the application has defined error
>> pages to display.
>>> If not, then it displays its own error pages. This
>> is undesirable
>>> for REST APIs since it totally rewrites the headers
>> and body. The
>>> only way I could find to get around it is to make
>> sure I output an
>>> entity body when returning an error. Then
>> GlassFish seems to let it
>>> through.
>>>
>>
>> Another solution is to add error pages to the
>> web.xml:
>>
>>
>> ttp://java.sun.com/developer/EJTechTips/2003/tt0114.ht
>> ml
>>
>> But ideally an option to switch off such default page
>> support would be
>> most useful.
>
> In my message above, I talked about application defined error pages,
> the same thing you mentioned here. My message is about creating a
> REST web service that returns an error as part of the API, and not
> wanting GlassFish to do anything but pass it to the client as-is. I
> don't want to return a web page.

> I want to return exactly what my programming told GlassFish to
> return, so defining error-pages in web.xml completely defeats the
> purpose.

Agreed, it was a suggestion to workaround GF restrictions.

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Markus Karg

So is that a bug in GF or is it not?

> > In my message above, I talked about application defined error pages,
> > the same thing you mentioned here. My message is about creating a
> > REST web service that returns an error as part of the API, and not
> > wanting GlassFish to do anything but pass it to the client as-is. I
> > don't want to return a web page.
>
> > I want to return exactly what my programming told GlassFish to
> > return, so defining error-pages in web.xml completely defeats the
> > purpose.
>
> Agreed, it was a suggestion to workaround GF restrictions.
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdelaplante
Offline
Joined: 2007-04-01

Well, GlassFish has sure made it difficult for me until I figured out a work around. I am using GlassFish 2.1 which was not designed with JAX-RS in mind. Maybe GlassFish V3 is aware of this issue and does not interfere with JAX-RS error responses.

Thanks,
Ryan

> So is that a bug in GF or is it not?
>
> > > In my message above, I talked about application
> defined error pages,
> > > the same thing you mentioned here. My message is
> about creating a
> > > REST web service that returns an error as part of
> the API, and not
> > > wanting GlassFish to do anything but pass it to
> the client as-is. I
> > > don't want to return a web page.
> >
> > > I want to return exactly what my programming
> told GlassFish to
> > > return, so defining error-pages in web.xml
> completely defeats the
> > > purpose.
> >
> > Agreed, it was a suggestion to workaround GF
> restrictions.
> >
> > Paul.
> >
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> users-unsubscribe@glassfish.dev.java.net
> > For additional commands, e-mail:
> users-help@glassfish.dev.java.net
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail:
> users-help@glassfish.dev.java.net

Paul Sandoz

On Jan 12, 2010, at 5:30 PM, glassfish@javadesktop.org wrote:

> Well, GlassFish has sure made it difficult for me until I figured
> out a work around. I am using GlassFish 2.1 which was not designed
> with JAX-RS in mind. Maybe GlassFish V3 is aware of this issue and
> does not interfere with JAX-RS error responses.
>

Unfortunately not. Basically a JAX-RS application is deployed as a
servlet so the behavior is the same as any deployed servlet.

I recommend logging a bug against GF stating that default error pages
should be disabled (or as a compromise a feature is supported to
disable default error pages).

Paul.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

rdelaplante
Offline
Joined: 2007-04-01

Ok, I have created a ticket:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11423

Thanks,
Ryan

> Unfortunately not. Basically a JAX-RS application is
> deployed as a
> servlet so the behavior is the same as any deployed
> servlet.
>
> I recommend logging a bug against GF stating that
> default error pages
> should be disabled (or as a compromise a feature is
> supported to
> disable default error pages).
>
> Paul.

beamso
Offline
Joined: 2008-01-07

Check out the javax.ws.rs.ext.ExceptionMapper interface.

rdelaplante
Offline
Joined: 2007-04-01

> Check out the javax.ws.rs.ext.ExceptionMapper
> interface.

Thank you. I spent some time looking at this interface and don't think it will change anything for me. It looks like I would create an exception mapper if I wanted JAX-RS to know about an existing exception in my application. I am throwing an exception that extends WebApplicationException, and the constructor does the same thing as the example code in the Jersey documentation.

I don't think the problem is Jersey or JAX-RS. I think when GlassFish sees an application returning an HTTP error code, it first looks to see if the application has defined error pages to display. If not, then it displays its own error pages. This is undesirable for REST APIs since it totally rewrites the headers and body. The only way I could find to get around it is to make sure I output an entity body when returning an error. Then GlassFish seems to let it through.

I've been doing my testing using the REST features in SoapUi.

Thanks,
Ryan

rdelaplante
Offline
Joined: 2007-04-01

Have a look at the W3C specification for HTTP response codes:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1

The introduction to the 4xx and 5xx statuses says:

> Except when responding to a HEAD request, the server SHOULD include an entity containing an
> explanation of the error situation, and whether it is a temporary or permanent condition. These status
> codes are applicable to any request method. User agents SHOULD display any included entity to
> the user.

So it looks like GlassFish is making my response conform to the W3C standard if I don't provide a response entity. It generates something readable for the client to display.

Ryan

rdelaplante
Offline
Joined: 2007-04-01

GlassFish (or the built-in Tomcat servlet container) seems to display an HTML error page only when I don't provide an entity (body) in the JAX-RS response when sending a status code >= 400.

In my resource methods (@GET, @POST, etc) I throw exceptions that extend WebApplicationException from JAX-RS. If I make my custom exception class look like this, then GlassFish doesn't muck with my response:

public class InvalidRequestException extends WebApplicationException {
public InvalidRequestException(String technicalDetail, String userMessage) {
super(Response.status(Status.BAD_REQUEST).header("Reason-Phrase",
userMessage).entity(technicalDetail).build());
}
}

Ryan