1 2 3 4 Previous Next 47 Replies Latest reply on Jan 20, 2010 8:00 PM by rdelaplante Go to original post
      • 30. Re: JAX-RS error code 500 = GlassFish HTML error page
        392 Guest
        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
        • 31. RE:  Re: JAX-RS error code 500 = GlassFish HTML error page
          392 Guest
          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
          • 32. Re: JAX-RS error code 500 = GlassFish HTML error page
            392 Guest
            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]
            • 33. Re: JAX-RS error code 500 = GlassFish HTML error page
              rdelaplante
              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
              • 34. Re: JAX-RS error code 500 = GlassFish HTML error page
                392 Guest
                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]
                • 35. Re: JAX-RS error code 500 = GlassFish HTML error page
                  rdelaplante
                  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 >
                  • 36. RE:  Re: JAX-RS error code 500 = GlassFish HTML error page
                    392 Guest
                    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]
                    • 37. Re: JAX-RS error code 500 = GlassFish HTML error page
                      392 Guest
                      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]
                      • 39. Re: JAX-RS error code 500 = GlassFish HTML error page
                        rdelaplante
                        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
                        • 40. Re: JAX-RS error code 500 = GlassFish HTML error page
                          rdelaplante
                          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
                          • 41. RE:  Re: JAX-RS error code 500 = GlassFish HTML error page
                            392 Guest
                            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
                            • 42. Re: JAX-RS error code 500 = GlassFish HTML error page
                              392 Guest
                              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
                              • 43. Re: JAX-RS error code 500 = GlassFish HTML error page
                                392 Guest
                                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]
                                • 44. Re: JAX-RS error code 500 = GlassFish HTML error page
                                  392 Guest
                                  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