Tomcat 的 ErrorPage 实现原理分析

使用Tomcat,一定见到过404,500的时候,见到过Tomcat提供的错误页面,例如请求的资源找不到的时候,响应状态码为404,这个时候的错误页面是这样的:

这些错误页面是 如何生成及定位展示的 ,如果我们要 自定义一些错误页面 ,又要怎么做呢?今天我们一起来看看,Tomcat中提供的ErrorPage处理。

我们以Manager应用为例,来了解整个流程。

  1. 首先,Manager应用的web.xml中,包含如下关于ErrorPage的配置:

这些配置,在应用部署,解析web.xml文件的时候,都会生成ErrorPage对应,设置到对应Context应用的属性中。

for (ErrorPage errorPage : webxml.getErrorPages().values() ) {

context. addErrorPage (errorPage);

}

(web.xml文件解析及应用部署,可以参考前面的文章《 WEB应用是怎样部署的?》)

下面的代码,就是StandardContext添加ErrorPage的内容。我们看到,按照对应配置的状态码,每个对应一个errorPage对象,保存到Map中。

上面是context设置errorPage。在应用请求处理时,如果对应的资源不存在,或者产生异常时,此时就需要根据配置的errorPage,进行对应的展示。

例如下面的代码,是在对应用的资源树上查找,如果不存在就会直接以 SC_NOT_FOUND 响应。

sendError的作用,是进行一个error标识的设置,便于后面对于该状态的使用。在其内部主要进行errorState和状态码的设置。

public boolean setError() {

boolean result = errorState .compareAndSet(0, 1 );

if (result) {

Wrapper wrapper = getRequest().getWrapper();

if (wrapper != null) {

wrapper.incrementErrorCount();

}

}

return result;

}

我们前面介绍过,整个请求处理流程中,会在Pipeline中包含一系列的Valve。在资源找不到或者异常产生时,Valve的后处理逻辑中, 在StandardHostValve中,后处理的代码有如下的逻辑

// Look for (and render if found) an application level error page

if (response. isErrorReportRequired ()) {

if (t != null) {

throwable(request, response, t);

} else {

status (request, response);

}

}

这里的response.isErrorReportRequired获取的就是上面对于error标识的设置。在这里,如果有异常产生会打印异常,如果是其它的状态标识,会走status处理。

status方法中,最主要的逻辑,就是根据状态码,获取对应配置的错误页面。

int statusCode = response.getStatus();

ErrorPage errorPage = context.findErrorPage(statusCode);

if (errorPage == null) {

// Look for a default error page

errorPage = context.findErrorPage(0);

}

status的代码,在获取对应的errorPage之后,会进行一个custom的操作,定向到对应的错误页面。代码如下:

从上面的代码中,我们看到定向的方式,使用的是RequestDispatcher. forward

ServletContext servletContext =

request.getContext().getServletContext();

RequestDispatcher rd =

servletContext.getRequestDispatcher( errorPage.getLocation() );

rd.forward(request.getRequest(), response.getResponse());

上面就是整个自定义errorPage的处理流程,概括起来,就是根据指定的错误页面位置,再在对应的状态码match的时候,进行forward 的处理。(重定向和转发,可以参见前面的文章《关于重定向和转发》)所以此处,我们可以进行一个个性化的404或者500的页面处理。

当然,ErrorPage的配置中,可以声明一个exceptionType,在指定的异常产生时,对应到相应的page上面,原理类似。

除上之外,需要说明的一点是,有些应用中,我们并没有显示的指定errorPage,但是在应用的请求中,依然可以看到熟悉的Tomcat错误页面。这个是因为,在Pipeline中,还有一个Vavle, ErrorReportValve

依然走前面的错误处理流程时,在根据错误码获取errorPage的时候,因为没有对应的配置,custom处理就跳过了。整个错误展示留给后面的ErrorReportValve。

在它的report方法中,对于状态码小于400的不做处理,其他的就会生成我们熟悉的错误页面,同时,加上对应的状态码,提示信息,如果有相应的stackTrace,会遍历显示到 页面上。

所以,这个其实是Tomcat代码里硬编码的一个。内容基本是这个样子:

所以,对于未指定errorPage的应用,看到的是相同样式的错误页面的,就是因为上面的原因。

时间: 2024-11-03 22:50:39

Tomcat 的 ErrorPage 实现原理分析的相关文章

Tomcat源码分析——请求原理分析(下)

前言 本文继续讲解TOMCAT的请求原理分析,建议朋友们阅读本文时首先阅读过<TOMCAT源码分析——请求原理分析(上)>和<TOMCAT源码分析——请求原理分析(中)>.在<TOMCAT源码分析——请求原理分析(中)>一文我简单讲到了Pipeline,但并未完全展开,本文将从Pipeline开始讲解请求原理的剩余内容. 管道 在Tomcat中管道Pipeline是一个接口,定义了使得一组阀门Valve按照顺序执行的规范,Pipeline中定义的接口如下: getBas

Tomcat源码分析——请求原理分析(中)

前言 在<TOMCAT源码分析——请求原理分析(上)>一文中已经介绍了关于Tomcat7.0处理请求前作的初始化和准备工作,请读者在阅读本文前确保掌握<TOMCAT源码分析——请求原理分析(上)>一文中的相关知识以及HTTP协议和TCP协议的一些内容.本文重点讲解Tomcat7.0在准备好接受请求后,请求过程的原理分析. 请求处理架构 在正式开始之前,我们先来看看图1中的Tomcat请求处理架构. 图1 Tomcat请求处理架构 图1列出了Tomcat请求处理架构中的主要组件,这里

深入理解HTTP协议、HTTP协议原理分析

深入理解HTTP协议.HTTP协议原理分析 目录(?)[+] http协议学习系列 1. 基础概念篇 1.1 介绍 HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写.它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本.其中最著名的就是RFC 26

Tomcat 学习进阶历程之Tomcat架构与核心类分析

前面的http及socket两部分内容,主要是为了后面看Tomcat源码而学习的一些网络基础.从这章开始,就开始实际深入到Tomcat的'内在'去看一看. 在分析Tomcat的源码之前,准备先看一下Tomcat的架构与一些核心类的简单分析,并简单介绍一下Tomcat是如何处理一次Http请求的.这部分内容有相当一部分来源于网络,在此,感谢原作者的贡献. Tomcat的总体架构 Tomcat的架构关系可以从Tomcat的配置文件server.xml中看到端倪. 从上图中可以看出Tomcat 的心脏

Tomcat7.0源码分析——请求原理分析(中)

前言 在<TOMCAT7.0源码分析--请求原理分析(上)>一文中已经介绍了关于Tomcat7.0处理请求前作的初始化和准备工作,请读者在阅读本文前确保掌握<TOMCAT7.0源码分析--请求原理分析(上)>一文中的相关知识以及HTTP协议和TCP协议的一些内容.本文重点讲解Tomcat7.0在准备好接受请求后,请求过程的原理分析. 请求处理架构 在正式开始之前,我们先来看看图1中的Tomcat请求处理架构. 图1 Tomcat请求处理架构 图1列出了Tomcat请求处理架构中的主

Servlet过滤器介绍之原理分析

zhangjunhd 的BLOG   写留言去学院学习发消息 加友情链接进家园 加好友 博客统计信息 51CTO博客之星 用户名:zhangjunhd文章数:110 评论数:858访问量:1923464无忧币:6720博客积分:6145博客等级:8注册日期:2007-02-03 热门专题更多>> Linux系统基础之菜鸟进阶 阅读量:2359 ARM驱动之Linux驱动程序设计入门 阅读量:2252 HTML5入门教程 阅读量:1392 深入浅出学MySQL 阅读量:1558 热门文章 基于T

Tomcat7.0源码分析——请求原理分析(上)

前言 谈起Tomcat的诞生,最早可以追溯到1995年.近20年来,Tomcat始终是使用最广泛的Web服务器,由于其使用Java语言开发,所以广为Java程序员所熟悉.很多人早期的J2EE项目,由程序员自己实现Jsp页面或者Servlet接受请求,后来借助Struts1.Struts2.Spring等中间件后,实际也是利用Filter或者Servlet处理请求,大家肯定要问了,这些Servlet处理的请求来自哪里?Tomcat作为Web服务器是怎样将HTTP请求交给Servlet的呢? 本文就

Webx3原理分析

WebX3原理分析 1 前言 抽空总结了Webx3框架,如有错误,欢迎指正! 2 背景知识 2.1 Maven Maven主要解决了以下两个问题: (1).它为项目构建引入了一个统一的接口,抽象了构建的生命周期,并为生命周期中的绝大部分任务提供了实现的插件.你不需要去关心这个生命周期里发生的事情,只需要把代码放在指定的位置,执行一条命令,整个构建过程就完成了. (2).其次,它为Java世界里的依赖引入了经纬度(groupId和artifactId),不再需要下载指定版本的jar包.拷贝到lib

Tomcat7.0源码分析——请求原理分析

Tomcat7.0源码分析--请求原理分析 谈起Tomcat的诞生,最早可以追溯到1995年.近20年来,Tomcat始终是使用最广泛的Web服务器,由于其使用Java语言开发,所以广为Java程序员所熟悉.很多人早期的J2EE项目,由程序员自己实现Jsp页面或者Servlet接受请求,后来借助Struts1.Struts2.spring等中间件后,实际也是利用Filter或者Servlet处理请求,大家肯定要问了,这些Servlet处理的请求来自哪里?Tomcat作为Web服务器是怎样将HTT