友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
JSP入门教程(DOC格式)-第8部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
HttpServletRequest 和 HttpServletResponse 才能进行下面的 session 操作和
页面重定向。
得到了 http 请求之后，可以获得请求对应的 session，判断 session 中的
username 变量是否为 null，如果不为 null，说明用户已经登录，就可以调用
doFilter 继续请求访问的资源。如果为 null，说明用户还没有登录，禁止用户
访问，并使用页面重定向跳转到 failure。jsp 页面显示提示信息。
session 中的username 实在登录的时候设置进去的，值就是登录用户使用的用
户名，详细代码可以参考 07…02/WEB…INF/src/LoginServlet。java，登录和注销
都写成了 servlet 并映射到/login。do 和/logout。do 这两个请求路径上。源代码
和 web。xml 配置请自行参考 07…02 中的例子，这里就不复述了。
我们再来看看页面重定向的写法，res。sendRedirect（）中使用的是
〃。。/failure。jsp〃，两个点（。。）代表当前路径的上一级路径，这是因为
SecurityFilter 负责处理的是/admin/下的请求，而/failure。jsp 的位置在
/admin/ 目录的上一级，所以加上两个点才能正确跳转到failure。jsp。当然这
里使用 forward（）也可以，但是要注意在不同路径下做请求转发会影响页面中相
对路径的指向。相关讨论在：第 3。4。2 节 “forward 导致找不到图片”。
7。3。 filter 所谓的特性
7。3。1。 请求映射
filter…mapping 和 servlet…mapping 都是将对应的 filter 或 servlet 映射到某
个 url…pattern 上，当客户发起某一请求时，服务器先将此请求与 web。xml 中定
义的所有 url…pattern 进行匹配，然后执行匹配通过的 filter 和 servlet。
你可以使用三种方式定义 url…pattern。
1。 直接映射一个请求。
ContactServlet
/contact。do
像第 6。3 节 “使用servlet 改写联系簿”中对 servlet 的映射，只有当
请求是/contact。do 的时候才会执行ContactServlet。/contact。do？id=1
或/contact。do？method=list&id=1 的请求也可以匹配到
ContactServlet，这是因为根据http 规范，请求的路径不包含问号以后
的部分。
72 / 148
…………………………………………………………Page 73……………………………………………………………
2。 映射一个路径下的所有请求。
EncodingFilter
/*
像第 7。1 节 “批量设置请求编码”中这样使用星号（*）的形式，可以
将某个路径下的所有请求都映射到 EncodingFilter 过滤器下，如果这个
路径下还有子路径，那么子路径下的请求也会被 EncodingFilter 过滤。
所以 /*这种写法就会过滤应用下所有的请求。
如果像第 7。2 节 “用filter 控制用户访问权限”中那样把映射配置成
/admin/*，就会只处理/admin/路径下的请求，不会处理根路径下的
/index。jsp 和/failure。jsp。
需要注意的是，这种写法必须以/开头，写成与绝对路径的形式，即便是
映射所有请求也要写成/*，不能简化成*。
3。 映射结尾相同的一类请求。
ControllerServlet
*。do
具体效果请参考 07…03 的例子，index。jsp 中有四个链接，分别指向/a1。do；
/a2。do； /xx/b1。do； /xx/yy/c1。do。
web。xml 中的ControllerServlet 会接收以。do 结尾的请求，并使用
forward 将请求转发到/test。jsp。
点击/a1。do 的情况。
73 / 148
…………………………………………………………Page 74……………………………………………………………
点击/xx/yy/c1。do 的情况。
这样做的一个好处是语义更清楚，只要看到以。do 结尾的请求就知道肯定
是交给 ControllerServlet 处理了，不管这个请求是在根路径还是子路径
下，都会准确无误的找到对应的 servlet。
缺点就是不同路径之间进行 forward，jsp 里就不能再使用相对路径了，
所以我们在 test。jsp 中使用request。getContextPath（）获得当前应用在
服务器中的位置（例子中是/07…03）将相对路径都组装成绝对路径，这种
用法在以后也会经常用到。
返回
最后需要注意的是，这种请求映射就不能指定某一路径了，它必须是以星
号（*）开始字母结尾，不能写成/*。do 的形式。
现在咱们也发现 java 的请求映射有多傻了，灵活配置根本是不可能的任务。
想要获得所有以 user 开头。do 结尾的请求吗？user*。do 在 url…pattern 是无法
识别的，只能配置成*。do，再去 servlet 中对请求进行筛选。
想要让一个 servlet 负责多个请求吗？/user/*；/admin/*；*。do 写在一起
url…pattern 也不认识，只能配成多个 servlet…mapping。
74 / 148
…………………………………………………………Page 75……………………………………………………………
ControllerServlet
/user/*
ControllerServlet
/admin/*
ControllerServlet
*。do
java 的复杂性在此处显露无疑。实际使用时，最好不要依赖web。xml 中的配置，
在自己的类中实现灵活配置才是正途。
7。3。2。 过滤链
其实在 07…02 这个例子里，我们使用了两个过滤器，EncodingFilter 负责设置
编码，SecurityFilter 负责控制权限，那这两个过滤器是怎么起作用的呢？它
们两个同时过滤一个请求时谁先谁后呢？
下面这个图会告诉我们答案。
所有的奥秘就在 Filter 中的FilterChain 中。服务器会按照web。xml 中过滤器
定义的先后循序组装成一条链，然后一次执行其中的 doFilter（）方法。执行的
顺序就如上图所示，执行第一个过滤器的 chain。doFilter（）之前的代码，第二
个过滤器的 chain。doFilter（）之前的代码，请求的资源，第二个过滤器的
75 / 148
…………………………………………………………Page 76……………………………………………………………
chain。doFilter（）之后的代码，第一个过滤器的 chain。doFilter（）之后的代码，
最后返回响应。
因此在 07…02 中执行的代码顺序是：
1。 执行 EncodingFilter。doFilter（）中 chain。doFilter（）之前的部分：
request。setCharacterEncoding（〃gb2312〃）；
2。 执行 SecurityFilter。doFilter（）中 chain。doFilter（）之前的部分：判断
用户是否已登录。
如果用户已登录，则访问请求的资源：/admin/index。jsp。
如果用户未登录，则页面重定向到：/failure。jsp。
3。 执行 SecurityFilter。doFilter（）中 chain。doFilter（）之后的部分：这里
没有代码。
4。 执行 EncodingFilter。doFilter（）中 chain。doFilter（）之后的部分：这里
也没有代码。
过滤链的好处是，执行过程中任何时候都可以打断，只要不执行
chain。doFilter（）就不会再执行后面的过滤器和请求的内容。而在实际使用时，
就要特别注意过滤链的执行顺序问题，像 EncodingFilter 就一定要放在所有
Filter 之前，这样才能确保在使用请求中的数据前设置正确的编码。
7。4。 filter 的详细配置
我们已经了解了 filter 的基本用法，还有一些细节配置在特殊情况下起作用。
在 servlet…2。3 中，Filter 会过滤一切请求，包括服务器内部使用 forward 转
发请求和的情况。
到了 servlet…2。4 中Filter 默认下只拦截外部提交的请求，forward 和 include
这些内部转发都不会被过滤，但是有时候我们需要 forward 的时候也用到
Filter，这样就需要如下配置。
TestFilter
anni。TestFilter
TestFilter
/*
REQUEST
FORWARD
76 / 148
…………………………………………………………Page 77……………………………………………………………
INCLUDE
EXCEPTION
这样 TestFilter 就会过滤所有状态下的请求。如果我们没有进行设置，默认使
用的就是 REQUEST。而EXCEPTION 是在 isErrorPage=〃true〃的情况下出现的，这
个用处不多，看一下即可。
这里 FORWARD 是解决request。getDispatcher（〃index。jsp〃）。forward（request；
response）；无法触发 Filter 的关键，配置上这个以后再进行 forward 的时候就
可以触发过滤器了。
Filter 还有一个有趣的用法，在 filter…mapping 中我们可以直接指定
servlet…mapping，让过滤器只处理一个定义在web。xml 中的 servlet。
TestFilter
TestServlet
TestServlet
anni。TestServlet
TestServlet
/TestServlet
直接指定 servlet…name，TestFilter 便会引用 TestServlet 配置的
url…pattern，在某些 filter 与 servlet 绑定的情况下不失为一个好办法。
77 / 148
…………………………………………………………Page 78……………………………………………………………
第 8 章 配置 listener 监听器
注意
还记得我们之前讲过的在线列表吗？第 4。2 节 “例子：在线列表”。我们曾经
说过那个在线列表无法判断用户非法退出，很可能造成在线列表无限增大，现在
我们可以用 listener 来弥补这一问题了。
如果你不满足以下任一条件，请继续阅读，否则请跳过此后的部分，进入下一章：
第 9 章 封装 taglib 组件。
1。 了解如何使用HttpSessionListener 监听 session 的销毁。
2。 了解如何使用 HttpSessionBindingListener 监听 session 的销毁。
8。1。 使用 HttpSessionListener
编写一个 OnlineUserListener。
package anni；
import java。util。List；
import javax。servlet。ServletContext；
import javax。servlet。http。HttpSession；
import javax。servlet。http。HttpSessionListener；
import javax。servlet。http。HttpSessionEvent；
public class OnlineUserListener implements HttpSessionListener ｛
public void sessionCreated（HttpSessionEvent event） ｛
｝
public void sessionDestroyed（HttpSessionEvent event） ｛
HttpSession session = event。getSession（）；
ServletContext application = session。getServletContext（）；
// 取得登录的用户名
String username = （String） session。getAttribute（〃username〃）；
// 从在线列表中删除用户名
List onlineUserList = （List）
application。getAttribute（〃onlineUserList〃）；
onlineUserList。remove（username）；
78 / 148
…………………………………………………………Page 79……………………………………………………………
System。out。println（username ＋ 〃超时退出。〃）；
｝
｝
OnlineUserListener 实现了 HttpSessionListener 定义的两个方法：
sessionCreated（）和 sessionDestroyed（）。这两个方法可以监听到当前应用中
session 的创建和销毁情况。我们这里只用到 sessionDestroyed（）在 session
销毁时进行操作就可以。
从 HttpSessionEvent 中获得即将销毁的 session，得到 session 中的用户名，
并从在线列表中删除。最后一句向 console 打印一条信息，提示操作成功，这只
是为了调试用，正常运行时删除即可。
为了让监听器发挥作用，我们将它添加到 web。xml 中：
anni。OnlineUserListener
以下两种情况下就会发生 sessionDestoryed （会话销毁）事件：
1。 执行 session。invalidate（）方法时。
既然 LogoutServlet。java 中执行 session。invalidate（）时，会触发
sessionDestory（）从在线用户列表中清除当前用户，我们就不必在
LogoutServlet。java 中对在线列表进行操作了，所以
LogoutServlet。java 的内容现在是这样。
public void doGet（HttpServletRequest request；HttpServletResponse
response）
throws ServletException； IOException ｛
// 销毁 session
request。getSession（）。invalidate（）；
// 成功
response。sendRedirect（〃index。jsp〃）；
｝
2。 如果用户长时间没有访问服务器，超过了会话最大超时时间，服务器就会
自动销毁超时的session。
79 / 148
…………………………………………………………Page 80……………………………………………………………
会话超时时间可以在 web。xml 中进行设置，为了容易看到超时效果，我们
将超时时间设置为最小值。
1
时间单位是一分钟，并且只能是整数，如果是零或负数，那么会话就永远
不会超时。
对应例子在 08…01，为了验证 OnlineUserListener 是否能正常执行，我们可以
登录两个用户，其中一个点击注销，另一个等待一分钟，然后可以在 console
中看到输出的信息。
8。2。 使用 HttpSessionBindingListener
HttpSessionBindingListener 虽然叫做监听器，但使用方法与
HttpSessionListener 完全不同。我们实际看一下它是如何使用的。
我们的OnlineUserBindingListener 实现了HttpSessionBindingListener接口，
接口中共定义了两个方法：valueBound（）和 valueUnbound（），分别对应数据绑
定，和取消绑定两个事件。
所谓对 session 进行数据绑定，就是调用 session。setAttribute（）把
HttpSessionBindingListener 保存进 session 中。我们在LoginServlet。java
中进行这一步。
// 把用户名放入在线列表
80 / 148
…………………………………………………………Page 81……………………………………………………………
session。setAttribute（〃onlineUserBindingListener〃； new
OnlineUserBindingListener（username））；
这就是HttpSessionBindingListener和HttpSessionListener之间的最大区别：
HttpSessionListener 只需要设置到 web。xml 中就可以监听整个应用中的所有
session。HttpSessionBindingListener 必须实例化后放入某一个 session 中，
才可以进行监听。
从监听范围上比较，HttpSessionListener 设置一次就可以监听所有 session，
HttpSessionBindingListener 通常都是一对一的。
正是这种区别成就了 HttpSessionBindingListener 的优势，我们可以让每个
listener 对应一个 username，这样就不需要每次再去 session 中读取username，
进一步可以将所有操作在线列表的代码都移入 listener，更容易维护。
valueBound（）方法的代码如下：
public void valueBound（HttpSessionBindingEvent event） ｛
HttpSession session = event。getSession（）；
ServletContext application = session。getServletContext（）；
// 把用户名放入在线列表
List onlineUserList = （List）
application。getAttribute（〃onlineUserList〃）；
// 第一次使用前，需要初始化
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！