in web.xml for your webapp
map a custom jsp for each returned HTTP status code e.g:
<error-page>
<error-code>401</error-code>
<location>/401.jsp</location>
</error-page>
<error-page>
<error-code>403</error-code>
<location>/403.jsp</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/404.jsp</location>
</error-page>
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
> From: ran...@hotmail.com
> To: users@tomcat.apache.org
> Subject: RE: [OT] servlet-specific error pages
> Date: Wed, 13 Apr 2011 20:10:48 -0400
>
>
> Hi Chris,
>
> > Of course. I was wondering about other exceptions or errors that maybe I
> > cannot control from that code.
>
> Are you referring to internal exceptions within Tomcat's own code or simply
> unexpected exceptions within the servlet's implemented code? If it's the
> later you could always just wrap your code with a try block that catches
> "Throwable" which will catch any possible exception thrown by Java and
> properly implemented library exceptions. Perhaps not ideal but considering
> the available options it might not be too bad.
>
> Technically speaking, catching Throwable isn't such a bad practice for
> end-user facing applications because you can at least redirect to a more
> elegant "Unexpected Exception has occurred" page rather than an error page
> showing a stack trace of a NullPointerException or some other unexpected
> errors due to programming mistakes as an example.
>
> Regards,
>
> Justin Randall
>
> > Date: Wed, 13 Apr 2011 16:11:09 -0400
> > From: ch...@christopherschultz.net
> > To: users@tomcat.apache.org
> > Subject: Re: [OT] servlet-specific error pages
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Justin,
> >
> > On 4/13/2011 9:17 AM, Justin Randall wrote:
> > > Hi Chris,
> > >
> > > I'm assuming the servlet is in control of generating all of the
> > > errors you are implying?
> >
> > Yes and no:
> >
> > > For example, if the servlet doesn't load properly and a 404 would be
> > > generated, the servlet would obviously not be in control of handling
> > > this exception and this would would have to make use of <error-page>
> > > directives in web.xml, specifically for <error-code> 404 which would
> > > redirect to a JSP that just so happens to be an XML file.
> >
> > Right, but I want the default 404 error page to be in HTML.
> >
> > Basically, I want two defaults.
> >
> > If the servlet spec allowed for <error-page> to include a <servlet-name>
> > filter, that's what I would use. But it doesn't :(
> >
> > > If I've understood what you're looking for correctly I've worked on
> > > similar projects in the past and what's worked well for me is
> > > leveraging MVC by using the RequestDispatcher to forward to relevant
> > > JSPs which happen to all be XML files with the contents populated
> > > either via JSP tags or EL. This way you can catch the
> > > exceptions/error conditions in your servlet, set the appropriate
> > > exception information within the request context and the dispatch to
> > > the correct JSP XML page.
> >
> > Of course. I was wondering about other exceptions or errors that maybe I
> > cannot control from that code.
> >
> > Thanks,
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iEYEARECAAYFAk2mA10ACgkQ9CaO5/Lv0PAvMgCgqk4ZiH5b75jrl25Kq73Po3hq
> > qCIAniutff9LdBlxKTUya36QdWp9e+eL
> > =j2iW
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
