Servlet的web应用（第十篇）

最新推荐文章于 2022-11-15 06:00:00 发布

往前的

最新推荐文章于 2022-11-15 06:00:00 发布

阅读量277

点赞数

分类专栏： servlet3.1规范文章标签： servlet web application 应用 web.xml

本文链接：https://blog.csdn.net/m0_37355951/article/details/113085201

版权

servlet3.1规范专栏收录该内容

16 篇文章 3 订阅

订阅专栏

一个web 应用是servlets、HTML 网页、classes和其他资源组成一个完整的应用，它运行在web服务器，web应用程序可以捆绑在一起，并在来自多个供应商的多个容器上运行

文章目录

10.1、在web服务器的 web应用

web应用是以某个路径开头，比如一个http://www.mycorp.com/catalog, 那么catalog的服务都是以/catalog开头的
servlet容器可以建立自动生成web应用程序规则，例如~user/映射可用于映射到基于/home/user/public_html/ 的web应用程序
默认情况下，web应用程序的实例必须随时在一个VM上运行，如果应用程序通过其部署描述符标记为”可分发“，则可以覆盖此行为，标记为可分发的应用程序必须遵循比普通web应用程序更严格的规则集，这些规则在整个说明书中都有阐述。

10.2、与ServletContext的关系

Servlet容器必须在Web应用程序和ServletContext之间强制一对一的对应关系，ServletContext对象为Servlet提供应用程序视图

10.3、Web 应用的元素

一个web应用可能由以下组成项
- Servlets
- JSP 页面
- 工具类
- 静态文档（HTML，图片，声音，等等）
- 客户端java applets，beans和classes
- 描述元数据，将上述的元素进行连接在一起，形成一个整体

10.4、部署层级

本规范定义了用于部署和打包目的层次结构，该结构可以存在于开发文件系统，归档文件或其他某种形式中，建议（但不是必须）servlet容器支持此结构作为运行时呈现。

10.5、目录结构

web应用程序作为目录的结构化层次结构存在。此层次的/作为根目录，例如对应在web容器中具有上下文路径/catalog的web应用程序，位于web应用程序层次结构基础上的index.html文件或位于WEB-INF/lib 中的jar里面（Jar里面的META-INF/resources目录）可以满足请求来自/catalog/index.html, 如果既存在根路径下META-INF/resources中，也存在WEB-INF/lib中的jar里面，优先使用根路径下META-INF/resources中的文件。
在应用程序层次结构中存在一个特殊目录，名为"WEB-INF".此目录包含于应用程序相关的所有内容，这些内容不再应用程序的文档目录中，大多数WEB-INF节点都不是应用程序的公共文档树的一部分，除了驻留在WEB-INF/lib目录中的JAR文件的META-INF/resources中打包的静态资源和JSP外，容器不能将WEB-INF目录中包含的其他文件直接提供给客户端，但是，使用ServletContext上的getResource和getResourceAsStream方法调用，Servlet代码可以看到WEB-INF目录的内容，并且可以使用RequestDispatcher调用公开WEB-INF目录的内容，因此，如果Application开发者需要从Servlet代码访问，他不想直接暴露给Web客户端的特定下应用程序的配置信息，则可以将其放在此目录下，由于请求以区分大小写的方式与资源映射匹配，因此，例如，客户端对/WEB-INF/foo 请求不应导致Web应用程序的内容位于/下，返回WEB-INF或其他任何形式的目录列表
WEB-INF目录的内容
- /WEB-INF/web.xml 部署描述文件
- /WEB-INF/classes/ 为servlet和工具类，这些类可以被应用程序加载
- /WEB-INF/lib/*.jar java的库，依赖的jar包，应用程序可以去加载任意jar包的内容
web应用程序类加载器必须首先从WEB-INF/classes目录中加载类，然后再从WEB-INF/lib目录中的库JAR中加载类。另外，除了将静态资源打包在JAR文件中的情况下置之外，客户端发出的访问WEB-INF/ 目录中资源的任何请求都必须返回SC_NOT_FOUND（404）响应

10.5.1、应用的目录结构示例

/index.html
/howto.jsp
/feedback.jsp
/images/banner.gif
/images/jumping.gif
/WEB-INF/web.xml
/WEB-INF/lib/jspbean.jar
/WEB-INF/lib/catalog.jar!/META-INF/resources/catalog/moreOffers/books.html
/WEB-INF/classes/com/mycorp/servlets/MyServlet.class
/WEB-INF/classes/com/mycorp/util/MyUtils.class

10.6、web应用的档案文件

web 应用程序可以使用标准java工具打包成war包（Web ARchive format file)
war有标准的文件组织结构，对于META-INF目录不能能够被请求直接访问，如果访问直接返回SC_NOT_FOUND (404)，它只是对servlet是可见，ServletContext可以通过getResource和getResourceAsStream方法进行调用。

10.7、web应用部署描述文件

web应用部署描述文件可以参考第14章，”部署描述“），它包含如下配置和部署信息
- ServletContext 初始化参数
- session 配置
- Servlet/JSP定义
- Servlet/JSP 映射
- MIME Type 映射
- Welcome File List ( 欢迎的文件列表)
- 错误页
- 安全

10.7.1、对依赖的扩展

需要用META-INF/MANIFEST.MF 来列出WAR对外部lib的依赖情况，对应manifest格式规则可以参考可选打包版本机制， web容器可以自动识别位于WEB-INF/lib库的文件

10.7.2、web应用类加载

容器用于在WAR中加载servlet的类加载器必须允许开放人员使用正确的java SE语义，使用getResource来加载WAR中的库JAR中包含的所有资源，如JAVA EE许可协议中所述，不属于Java EE产品的servlet容器不应允许应用程序覆盖Java SE所做的Java SE 平台类，例如java.* 和javax.* 开头的命名空间是不允许的修改的，容器不应允许应用程序覆盖或访问容器的实现类，还建议实现应用程序类加载器，以便优先于容器级库JAR中的类和资源加载WAR中打包的类和资源，一个实现还必须保证对于容器中部署的每个web应用程序，对Thread.currentThread.getContextClassLoader()的调用都必须返回实现本节中指定的约定的ClassLoader实例,此外，对于每个已经部署的web应用程序，ClassLoader实例必须是一个单独的实例。在向web应用程序运行任何回调（包含监听器回调）都应该使用容器所设置的上下文ClassLoader,并在回调返回后将其设置回原始的ClassLoader.

10.8、替换一个web应用

服务器应该能够在不重新启动容器的情况下用新版本替换应用程序，替换应用程序时，容器应提供一种健壮的方法来保留该应用程序内的会话数据。

10.9、异常处理

10.9.1、请求属性

在发生错误的时候，应用需要返回具体错误信息

如果错误处理程序的位置是servlet或JSP页面

容器创建原始的未包装请求和响应对象传送给servlet或jsp页面处理
如果RequestDispatcher.forward到一个错误资源时候，错误信息将设置会请求路径和相关的属性
请求属性如表所示

请求属性	类型
javax.servlet.error.status_code	java.lang.Integer
javax.servlet.error.exception_type	java.lang.Class
javax.servlet.error.message	java.lang.String
javax.servlet.error.exception	java.lang.Throwable
javax.servlet.error.request_uri	java.lang.String
javax.servlet.error.servlet_name	java.lang.String

本规范的版本2.3属性列表中引入了异常对象后，异常类型和错误属性就变得多余了，保留他们是为了与早期版本的API向后兼容。

10.9.2、错误页

在部署描述文件中（web.xml）允许开发者自定义错误页面，servlet或filter类发生异常的时候可以调用sendError方法（参数为具体状态code），然后去拿这个状态码去匹配错误页列表。
servlet和filter处理过程中可能会抛出异常
- 运行异常或错误
- ServletExceptions 或其子类
- IOException 或其子类
web应用程序可能已使用exception-type元素声明了错误页面，在这种情况下，容器通过将抛出的异常与使用异常类型元素的错误页面定义列表进行比较匹配异常类型，匹配导致容器返回位置条目中指示的资源，类层次结构中最接近的匹配将会命中。
如果没有通过类层次结构匹配使用包含异常类型的错误页面声明，并且抛出的异常是ServletException或其子类，则容器将提取包装的异常，如ServletException.getRootCause方法所定义的，对错误页面声明进行第二遍处理，再次尝试与错误页面声明进行匹配，但改用包装的异常。
在部署描述符中使用exception-type元素的错误页面声明必须唯一，直到exception-type的类名为止。同样，使用状态码元素的错误页面声明在部署描述符中必须唯一，直到状态码为止。
如果部署描述符中的错误页面元素不包含异常类型或错误代码元素，则错误页面为默认的错误页面。
如果servlet生成错误并没有被上述的错误页机制处理，这个容器必须确保在发送响应对象时候状态是500
默认的servlet和容器将使用sendError方法发送4xx和5xx状态响应，以便可以调用错误机制，默认的servlet和容器将对2xx和3xx响应使用设置setStatus方法，并不会调用错误页面处理机制。
如果应用程序使用第2-10页的第2.3.3.3节，异步处理中所述的异步操作，则应用程序有责任处理应用程序创建的线程中的所有错误。容器可以处理通过AsyncContext.start发生的线程中的错误，有关处理在AsyncContext。dispatch期间发生的错误，请参见第n节， “必须在容器中捕获和处理在执行分派方法期间可能发生的任何错误或异常"(在页面2-16)

10.10、欢迎文件

总一句话，访问一个urI时候，没有对应mapping的filter或servlet，这个时候就会去查找部署描述符文件（web.xml)是否有对应欢迎页面的文件名称，如果有就返回这个文件信息，反之就返回404
例子
- ```
// web.xml 部分内容，就是欢迎页文件名称
<welcome-file-list>
	<welcome-file>index.html</welcome-file>
  <welcome-file>default.jsp</welcome-file>
</welcome-file-list>

// WAR中静态资源情况
/foo/index.html
/foo/default.jsp
/foo/orderform.html
/foo/home.gif
/catalog/default.jsp
/catalog/products/shop.jsp
/catalog/products/register.jsp
```
- 请求uri包含/foo 重定向到/foo/
- 请求uri 包含/foo/ 返回/foo/index.html
- 请求uri包含/catalog 重定向到/catalog/default.jsp
- 请求uri包含/catalog/ 返回/catalog/default.jsp
- 请求uri包含/catalog/index.html 将会返回404
- 上述所有静态内容也可以打包在JAR文件中，而上面列出的内容打包在jar文件的META-INF/resources目录中。然后，可以将JAR文件包含在web应用程序的WEB-INF/lib目录中

10.11、web 应用环境

鼓励（但并非必须）不属于Java EE技术的实现中的Servlet容器实现第15.2.2节“web应用程序”中描述的应用程序环境功能和java EE规范，如果他们没有实现支持此环节所需的功能，则在部署依赖于该环境的应用程序时，容器应提供警告。

10.12、web应用部署

将Web应用程序部署到容器中时，必须按此顺序执行以下步骤，然后web应用程序才开始处理客户端请求。
- 实例化在web.xml配置的监听器
- 如果监听器实现ServletContextListener,会调用contextInitized()方法
- 实例化在web.xml配置的过滤器，并调用init方法完成初始化
- 实例化在web.xml配置的servlet，并按照按照顺序启动，并且每个servlet调用init()初始化方法。