Reading – Java™ Servlet Specification Version 2.4 – Web Applications
Relationship to ServletContext
一个 Web Application 与 ServletContext 是一一对应的.
WEB-INF Directory
位于 WEB-INF 目录中的任何文件都不能直接被用于处理客户端请求. 不过, WEB-INF 目录内的内容可以使用 ServletContext 的 getResource and getResourceAsStream 方法访问, 也可以通过 RequestDispatcher 方法暴露给外部. 因此, 如果应用程序开发者需要从 servlet 访问特定应用程序信息但又不想把它们直接暴露给客户端, 他/她可以把它们放在这个目录下.
Web application class loader 必须首先加载 WEB-INF/classes 目录下的类, 然后加载 WEB-INF/lib 目录下的 JARs. 客户端的任何企图访问 WEB-INF/ 目录下资源的请求都必须返回一个 SC_NOT_FOUND(404) response.
Web Application Archive File
Web applications 都可以打包成一个 Web ARchive(WAR) 格式文件. META-INF/ 目录包含对 Java Archive Tool 有用的信息. 这个目录下的内容也不能被客户端直接访问到, 尽管它们可以通过 ServletContext 的 getResource and getResourceAsStream 访问到. 客户端的任何企图访问 META-INF/ 目录下资源的请求都必须返回一个 SC_NOT_FOUND(404) response.
Dependencies On Extensions
这里的 extensions 是指一些可由容器提供、由所有 web applications 共享使用的 JARs 或其它 Resources.
如果有这种依赖, 应用程序开发者必须在 WAR 文件中提供一个 META-INF/MANIFEST.MF, 列出该 WAR 所需要的所有 extensions. manifest 的格式应当遵从标准的 manifest format. 在发布时, Web container 会依据 Optional Package Versioning mechanism (http://java.sun.com/j2se/1.4/docs/guide/extensions/) 定义的规则提供正确版本的 extensions 给应用程序.
Web containers 也必须能够识别出 WAR 文件中 WEB-INF/lib 的 JARs 里的 manifest 所声明的依赖.
Web Application Class Loader
Web Application Class Load 可以 getResource 装载 WAR 里的 JARs 中的 resources.
Replacing a Web Application
服务器应当能够在不需要重启 servlet container 的情况下使用新版本替换旧版本应用程序. 当应用程序正在被替换时, container 应该提供一种健壮的方法保存被替换应用程序里的 session 数据.
Error Handling – Request Attributes
对于用于显示错误页面的 servlet 或 JSP:
• 最初由 container 所创建的 request and response 对象会传递给这个 servlet or JSP page.
• response setStatus 方法已被禁用, 即使调用也将被忽略掉.
• request path and attributes are set as if a RequestDispatcher.forward to the error resource had been performed.
• 下列 request attributes 必须设置:
Request Attributes Type
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
Error Handling – Error Pages
在部署描述符中有几种方式可以指定 Error Pages:
- status-code: 这是根据 response.sendError() 所设置的状态代码来查找 error page.
- exception-type: 这是根据异常类型来查找 error page.
If no error-page declaration containing an exception-type fits using the class-heirarchy match, and the exception thrown is a ServletException or subclass thereof, the container extracts the wrapped exception, as defined by the ServletException.getRootCause method. A second pass is made over the error page declarations, again attempting the match against the error page declarations, but using the wrapped exception instead.
部署描述符中, exception-type 的 exception class name 必须唯一, 同样, status-code element 中的 status code 也必须唯一.
The error page mechanism described does not intervene when errors occur when invoked using the RequestDispatcher or filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated.
如果一个 servlet 产生一个错误但没有被 error page 机制处理, container 必须确保发送 status 500 的响应.
默认 servlet and container 会使用 sendError 方法发送 4xx and 5xx status responses, 这样 error mechanism 会被调用. 默认 servlet and container 会使用 setStatus 方法发送 2xx and 3xx responses, 这样不会调用 error page mechanism.
sendError 方法与 sendStatus(用来发送没有错误的status code) 方法还是有一定区别的 
Welcome Files
部署描述符中可以设置当 request uri 不完整时, 使用哪些页面来响应请求. 这些 webcome files 既不能以 “/” 开头, 也不能以 “/” 结尾.
Web server 必须按照在部署描述符中的顺序将每个 welcome file 附加到不完整请求路径上, 检查是否在 WAR 中有这样的静态资源或者 servlet 映射这个请求 URI 上. Web container 必须将请求发送给 WAR 中第一个匹配的资源上. container 可能通过一个 forward, 一个 redirect, 或者一个特定于容器的机制(a container specific mechanism that is indistinguishable from a direct request), 将请求发送给 welcome resource.
如果按照以上描述的方式没有找到任何匹配的 welcome file, container 可能会按照它认为合适的方式处理这个请求. 对某些配置而言, 这可能意味着将返回一个目录列表或者返回一个 404 响应.
Web Application Environment
Servlet 可以通过如下部署描述符中所描述的信息获得外部资源:
• env-entry
• ejb-ref
• ejb-local-ref
• resource-ref
• resource-env-ref
Web Application Deployment
在一个 Web Application 部署以后、处理客户端请求之前, 必须执行如下系列步骤:
- 为部署描述符中 <listener> element 所标识的每个 event listener 实例化一个实例.
- 对于已经实例化后的 ServletContextListener 的实例, 调用其 contextInitialized() 方法.
- 为部署描述符中 <filter> element 所标识的每个 filter 实例化一个实例, 并调用每个 filter 实例的 init() 方法(注意: 是先实例化所有 filter, 然后再逐一调用 init() 方法).
- 按照 load-onstartup element 的值所定义的顺序, 为每个包含 <load-on-startup> element 的 <servlet> element 所标识每个 servlet 实例化一个实例, 并调用每个 servlet 实例的 init() 方法.
Categorized in: Java · Tagged with: Java, Servlet
(No Ratings Yet)
Loading ...
(
