在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction和session在某些语境下的含义是相同的。

　　session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程 能称之为一个session。有时候我们能看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关 闭这个期间①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，他可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从 登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接，也有可能是指含义 ①，其中的差别只能靠上下文来推断②。

　　然而当session一词和网络协议相关联时，他又往往隐含了“面向连接”和/或“保持状态”这样两个含义，“面向连接”指的是在通信双方在通 信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，和此相对的是写信，在你把信发出去的时候你并不能确认对方的地址是否正确，通 信渠道不一定能建立，但对发信人来说，通信已开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来，使得消息之间能互相依赖，比如一个服务员 能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或“一个POP3 session”③。

　　而到了web服务器蓬勃发展的时代，session在web研发语境下的语义又有了新的扩展，他的含义是指一类用来在客户端和服务器之间保持状 态的解决方案④。有时候session也用来指这种解决方案的存储结构，如“把xxx保存在session里”⑤。由于各种用于web研发的语言在一定程 度上都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决方案，比如经常把Java里提供的 javax.servlet.http.HttpSession简称为session⑥。

　　鉴于这种混乱已不可改动，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。

　　在本文中，使用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表达含义⑤，使用具体的“HttpSession”来表达含义⑥

　　二、HTTP协议和状态保持

　　HTTP协议本身是无状态的，这和HTTP协议本来的目的是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没 有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客和一个自动售货机或一个普通的（非会员制）大卖场之间的关系相同。

　　然而聪明（或贪心？）的人们非常快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能相同。这种需求 一方面迫使HTML逐步添加了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协 议也添加了文件上载、cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机 制则是又一种在客户端和服务器之间保持状态的解决方案。

　　让我们用几个例子来描述一下cookie和session机制之间的差别和联系。笔者原来常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：

　　1、该店的店员非常厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。

　　2、发给顾客一张卡片，上面记录着消费的数量，一般更有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会和以前或以后的消费相联系起来。这种做法就是在客户端保持状态。

　　3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

　　由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的 是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存 一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上他更有其他选择。

　　三、理解cookie机制

　　cookie机制的基本原理就如上面的例子相同简单，不过更有几个问题需要解决：“会员卡”怎么分发；“会员卡”的内容；及客户怎么使用“会员卡”。

　　正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特别的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或VBScript也能生成cookie。

　　而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作 用范围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出 示，如果某家分店还发行了自己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

　　cookie的内容主要包括：名字，值，过期时间，路径和域。

　　其中域能指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也能指定一个域下的具体某台机器比如www.google.com或froogle.google.com，能用飘柔来做比。

　　路径就是跟在域名后面的URL路径，比如/或/foo等等，能用某飘柔专柜做比。

　　路径和域合在一起就构成了cookie的作用范围。

　　如果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期 的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览 器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

　　存储在硬盘上的cookie能在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方 式。对于IE，在一个打开的窗口上按Ctrl-N（或从文件菜单）打开的窗口能和原窗口共享，而使用其他方式新开的IE进程则不能共享已打开的窗口的内存 cookie；对于Mozilla Firefox0.8，所有的进程和标签页都能共享同样的cookie。一般来说是用javascript的window.open打开的窗口会和原窗口 共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程式研发者造成非常 大的困扰。

　　下面就是个goolge设置cookie的响应头的例子

HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

　　这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分

浏览器在再次访问goolge的资源时自动向外发送cookie

　　使用Firefox能非常容易的观察现有的cookie的值

　　使用HTTPLook配合Firefox能非常容易的理解cookie的工作原理。

IE也能设置在接受cookie前询问

　　这是个询问接受cookie的对话框。

　　四、理解session机制

　session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

　　当程式需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个和此session相关联的session id，session id的值应该是个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

　　保存这个session id的方式能采用cookie，这样在交互过程中浏览器能自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程式生成的 cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764， 他的名字就是JSESSIONID。

　　由于cookie能被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://..... /xxx;jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 另一种是作为查询字符串附加在URL后面，表现形式为http://..... /xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有差别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程式参数区分开来。

　　为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

　　另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单

<form name="testform" action="/xxx">
<input type="text">
</form>

　　在被传递给客户端之前将被改写成

<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>

　　这种技术目前已较少应用，笔者接触过的非常古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。实际上这种技术能简单的用对action应用URL重写来代替。

　　在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实能想象一下会员卡的例子，除非顾客主 动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是相同的，除非程式通知服务器删除一个session，否则服务器会一直 保留，程式一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器他将要关闭，因此服务器根本不会有机会知道浏览器已关闭，之所以 会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

　　恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就能认为客户端已停止了活动，才会把session删除以节省存储空间。

　　五、理解javax.servlet.http.HttpSession

　　HttpSession是Java平台对session机制的实现规范，因为他仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

　　首先，Weblogic Server提供了一系列的参数来控制他的HttpSession的实现，包括使用cookie的开关选项，使用URL重写的开关选项，session持 久化的设置，session失效时间的设置，及针对cookie的各种设置，比如设置cookie的名字、路径、域，cookie的生存时间等。

　　一般情况下，session都是存储在内存里，当服务器进程被停止或重启的时候，内存里的session也会被清空，如果设置了session 的持久化特性，服务器就会把session保存到硬盘上，当服务器进程重新启动或这些信息将能够被再次使用，Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

　　复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然能从其他进程中取得session。

　　cookie生存时间的设置则会影响浏览器生成的cookie是否是个会话cookie。默认是使用会话cookie。有兴趣的能用他来试验我们在第四节里提到的那个误解。

　　cookie的路径对于web应用程式来说是个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得他和其他服务器有明显的差别。后面我们会专题讨论。

　　关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

　　六、HttpSession常见问题

　　（在本小节中session的含义为⑤和⑥的混合）

　　1、session在何时被创建

　　一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程式调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

　　由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭他。

　　2、session何时被删除

　　综合前面的讨论，session在下列情况下被删除a.程式调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

　　3、怎么做到在浏览器关闭时删除session

　　严格的讲，做不到这一点。能做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。不过对于浏览器崩溃或强行杀死进程这些非常规手段仍然无能为力。

　　4、有个HttpSessionListener是怎么回事

　　你能创建这样的listener去监视session的创建和销毁事件，使得在发生这样的事件时你能做一些相应的工作。注意是session的 创建和销毁动作触发listener，而不是相反。类似的和HttpSession有关的listener更有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。

　　5、存放在session中的对象必须是可序列化的吗

　　不是必需的。需求对象可序列化只是为了session能够在集群中被复制或能够持久保存或在必要时server能够暂时把session交换出 内存。在Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化 的对象，在session销毁时会有一个Exception，非常奇怪。

　　6、怎么才能正确的应付客户端禁止cookie的可能性

　　对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

　　7、开两个浏览器窗口访问应用程式会使用同一个session还是不同的session

　　参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式及不同的cookie存储方式都会对这个问题的答案有影响。

　　8、怎么防止用户打开两个浏览器窗口操作导致的session混乱

　　这个问题和防止表单多次提交是类似的，能通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端，同时保存在 session里，客户端提交表单时必须把这个id也返回服务器，程式首先比较返回的id和保存在session里的值是否一致，如果不一致则说明本次操 作已被提交过了。能参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口，一般不设置这个id，或使用独立的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改操 作，这样就能不用设置。

　　9、为什么在Weblogic Server中改动session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改动，需要向其他服务器进程复制新的session值。

　　10、为什么session不见了

　　排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在iPlanet6SP1加若干补丁的Solaris版 本上倒也遇见过；浏览器插件的可能性次之，笔者也遇见过3721插件造成的问题；理论上防火墙或代理服务器在cookie处理上也有可能会出现问题。

　　出现这一问题的大部分原因都是程式的错误，最常见的就是在一个应用程式中去访问另外一个应用程式。我们在下一节讨论这个问题。

　　七、跨应用程式的session共享

常常有这样的情况，一个大项目被 分割成若干小项目研发，为了能够互不干扰，需求每个小项目作为一个独立的web应用程式研发，可是到了最后忽然发现某几个小项目之间需要共享一些信息，或 想使用session来实现SSO(single sign on)，在session中保存login的用户信息，最自然的需求是应用程式间能够访问彼此的session。

　　然而按照Servlet规范，session的作用范围应该仅仅限于当前应用程式下，不同的应用程式之间是不能够互相访问对方的session 的。各个应用服务器从实际效果上都遵守了这一规范，不过实现的细节却可能各有不同，因此解决跨应用程式session共享的方法也各不相同。

　　首先来看一下Tomcat是怎么实现web应用程式之间session的隔离的，从Tomcat设置的cookie路径来看，他对不同的应用程 式设置的cookie路径是不同的，这样不同的应用程式所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程式，发送给服务器的session id也能是不同的。

　　根据这个特性，我们能推测Tomcat中session的内存结构大致如下。

　　笔者以前用过的iPlanet也采用的是同样的方式，估计SunONE和iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思 路非常简单，实际实行起来也不难。要么让所有的应用程式共享一个session id，要么让应用程式能够获得其他应用程式的session id。

　　iPlanet中有一种非常简单的方法来实现共享一个session id，那就是把各个应用程式的cookie路径都设为/（实际上应该是/NASApp，对于应用程式来讲他的作用相当于根）。

<session-info>
<path>/NASApp</path>
</session-info>

　　需要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程式的前缀，使得setAttribute("name", "neo")变成setAttribute("app1.name", "neo")，以防止命名空间冲突，导致互相覆盖。

在Tomcat中则没有这么方便的选择。在Tomcat版本3上，我们还能有一些手段来共享session。对于版本4以上的 Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或客户端cookie，URL参数或隐藏字段等手段。

　　我们再看一下Weblogic Server是怎么处理session的。

　　从截屏画面上能看到Weblogic Server对所有的应用程式设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就能共享session了呢？然而一个小实验即可证实即使不同的应用程式使用的是同一个session，各个应用程式仍然只能访问自 己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下

　　对于这样一种结构，在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据 库、JMS或客户端cookie，URL参数或隐藏字段等手段，更有一种较为方便的做法，就是把一个应用程式的session放到 ServletContext中，这样另外一个应用程式就能从ServletContext中取得前一个应用程式的引用。示例代码如下，

　　应用程式A

context.setAttribute("appA", session);

　　应用程式B

contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

　　值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器能处于安全的原因对于context.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通过。

　　那么Weblogic Server为什么要把所有的应用程式的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程式都能共享认证的信息。一个 简单的实验就能证实这一点，修改首先登录的那个应用程式的描述符weblogic.xml，把cookie路径修改为/appA访问另外一个应用程式会重 新需求登录，即使是反过来，先访问cookie路径为/的应用程式，再访问修改过路径的这个，虽然不再提示登录，不过登录的用户信息也会丢失。注意做这个 实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过session来实现的。具 体请参看[7] secion 14.8 Authorization，你能修改所附的示例程式来做这些试验。

　　八、总结

　　session机制本身并不复杂，然而其实现和设置上的灵活性却使得具体情况复杂多变。这也需求我们不能把仅仅某一次的经验或某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。

　　关于作者：

　　郎云鹏（dev2dev ID: hippiewolf），软件工程师，从事J2EE研发
电子邮件：langyunpeng@yahoo.com.cn
地址：大连软件园路31号科技大厦A座大连博涵咨询服务有限公司

/**
 * Tomcat GET方式表单提交乱码解决。
 * @author BeanSoft
 *
 */
public class TomcatFormFilter implements Filter {
 public void destroy() {
  // TODO Auto-generated method stub
  
 }

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  // 1. ServletRequest 转成 HttpServletRequest
  HttpServletRequest req = (HttpServletRequest)request;
  
  // 2. 如果是GET，就生成一个Wrapper对象，覆盖获取参数的方法进行转码
  if("GET".equalsIgnoreCase(req.getMethod())) {
   req = new MyRequest(req);
  }
  // 3. 如果是POST，request.setCharacterEncoding("UTF-8")
  else if("POST".equalsIgnoreCase(req.getMethod())) {
   req.setCharacterEncoding("UTF-8");
  }
  // 4.调用chain.doFilter继续向后执行
  chain.doFilter(req, response);
 }

 public void init(FilterConfig arg0) throws ServletException {
  // TODO Auto-generated method stub
  
 }

}

/**
 * 包装器，覆盖 getParameter()和 getParameterValues() 这两个方法来进行转码。
 * @author BeanSoft
 *
 */
class MyRequest extends HttpServletRequestWrapper {

 public MyRequest(HttpServletRequest request) {
  super(request);
  // TODO Auto-generated constructor stub
 }
 
 /**
  * 字符串转码。
  * @param input 输入字符串
  * @param srcEncoding 源字符串的编码
  * @param targetEncoding 目标编码
  * @return 转换过的内容
  */
 public String changeEncoding(String input, String srcEncoding, String targetEncoding) {
  try {
   // 1. 获取源编码的bytes[]
   byte[] data = input.getBytes(srcEncoding);
   // 2. 将bytes[]按照制定编码转换为String
   return new String(data, targetEncoding);
  } catch (UnsupportedEncodingException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
  
  return input;
 }

 @Override
 public String getParameter(String name) {
  String value = super.getParameter(name);
  
  if(value != null) {
   value = changeEncoding(value, "ISO8859-1", "UTF-8");
  }
  return value;
 }

 @Override
 public String[] getParameterValues(String name) {
  String[] values = super.getParameterValues(name);
  if(values != null && values.length > 0) {
   for (int i = 0; i < values.length; i++) {
    String value = values[i];
    
    values[i] = changeEncoding(value, "ISO8859-1", "UTF-8");
   }
  }
  return values;
 }
 
}

1.JMS概述

JMS 支持两种消息类型PTP （Point-to-Point）和Pub/Sub（Publish-Subscribe），分别称作：PTP Domain 和Pub/Sub Domain。
PTP的主要特点是：
1）一条消息只有一个使用者
2）不存在时间限制
Pub/Sub主要特点有：
1）一条消息可以有多个使用者
2）存在时间限制。订阅者可以使用持久方式来订阅消息，但是也会过期或者取消订阅

这两种接口都继承统一的JMS Parent 接口，JMS 主要接口如下所示：

以下是对这些接口的简单描述：

ConnectionFactory ：连接工厂，JMS 用它创建连接

Connection ：JMS 客户端到JMS Provider 的连接

Destination ：消息的目的地

Session： 一个发送或接收消息的线程

MessageProducer： 由Session 对象创建的用来发送消息的对象

MessageConsumer： 由Session 对象创建的用来接收消息的对象

2.JMS消息模型

JMS 消息由以下几部分组成：消息头，属性，消息体。

消息头(Header) -消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：JMSDestination,JMSMessageID等。

属性(Properties) -除了消息头中定义好的标准属性外，JMS提供一种机制增加新属性到消息头中，这种新属性包含以下几种：

标准的JMS 消息头包含以下属性：

JMSDestination --消息发送的目的地。

JMSDeliveryMode --传递模式，有两种模式：PERSISTENT和NON_PERSISTENT，PERSISTENT表示该消息一定要被送到目的地，否则会导致应用错误。 NON_PERSISTENT表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。

JMSMessageID 唯一识别每个消息的标识，由JMS Provider 产生。

JMSTimestamp 一个消息被提交给JMS Provider 到消息被发出的时间。

JMSCorrelationID 用来连接到另外一个消息，典型的应用是在回复消息中连接到原消息。

JMSReplyTo 提供本消息回复消息的目的地址。

JMSRedelivered如果一个客户端收到一个设置了JMSRedelivered属性的消息，则表示可能该客户端曾经在早些时候收到过该消息，但并没有签收(acknowledged)。

JMSType 消息类型的识别符。

JMSExpiration 消息过期时间，等于QueueSender 的send方法中的timeToLive值或TopicPublisher 的publish 方法中的timeToLive值加上发送时刻的GMT时间值。如果timeToLive值等于零，则JMSExpiration被设为零，表示该消息永不过期。如果发送后，在消息过期时间之后消息还没有被发送到目的地，则该消息被清除。

JMSPriority 消息优先级，从0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求JMS Provider严格按照这十个优先级发送消息，但必须保证加急消息要先于普通消息到达。

消息体(Body) - JMS API定义了5种消息体格式，也叫消息类型，你可以使用不同形式发送接收数据并可以兼容现有的消息格式，下面描述这5种类型：

Message是以上5类的基础。最常用的是ObjectMessage和TextMessage

3.消息的同步异步接收

消息的同步接收

同步接收是指客户端主动去接收消息，JMS 客户端可以采用MessageConsumer的receive方法去接收下一个消息。

消息的异步接收

异步接收是指当消息到达时，主动通知客户端。JMS客户端可以通过注册一个实现MessageListener接口的对象到MessageConsumer，这样，每当消息到达时，JMS Provider 会调用MessageListener中的onMessage 方法。

4.PTP模型

PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列，接收方从队列接收消息，队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提供工具管理队列的创建、删除。JMS PTP模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。

下面描述JMS PTP 模型中的主要概念和对象：

4.Pub/Sub模型

JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)。

主题可以被认为是消息的传输中介，发布者(publisher)发布消息到主题，订阅者(subscribe)从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。

下面描述JMS Pub/Sub 模型中的主要概念和对象：

Listener是Servlet的监听器，它可以监听客户端的请求、服务端的操作等。通过监听器，可以自动激发一些操作，比如监听在线的用户的数量。当增加一个HttpSession时，就激发sessionCreated(HttpSessionEvent se)方法，这样就可以给在线人数加1。常用的监听接口有以下几个：

ServletContextAttributeListener监听对ServletContext属性的操作，比如增加、删除、修改属性。

ServletContextListener监听ServletContext。当创建ServletContext时，激发contextInitialized(ServletContextEvent sce)方法；当销毁ServletContext时，激发contextDestroyed(ServletContextEvent sce)方法。

HttpSessionListener监听HttpSession的操作。当创建一个Session时，激发session Created(HttpSessionEvent se)方法；当销毁一个Session时，激发sessionDestroyed (HttpSessionEvent se)方法。

HttpSessionAttributeListener监听HttpSession中的属性的操作。当在Session增加一个属性时，激发attributeAdded(HttpSessionBindingEvent se) 方法；当在Session删除一个属性时，激发attributeRemoved(HttpSessionBindingEvent se)方法；当在Session属性被重新设置时，激发attributeReplaced(HttpSessionBindingEvent se) 方法。

下面我们开发一个具体的例子，这个监听器能够统计在线的人数。在ServletContext初始化和销毁时，在服务器控制台打印对应的信息。当ServletContext里的属性增加、改变、删除时，在服务器控制台打印对应的信息。

要获得以上的功能，监听器必须实现以下3个接口：

HttpSessionListener

ServletContextListener

ServletContextAttributeListener

我们看具体的代码，见示例14-9。

【程序源代码】

1 // ==================== Program Discription =====================
2 // 程序名称：示例14-9 : EncodingFilter .java
3 // 程序目的：学习使用监听器
4 // ==============================================================
5 import javax.servlet.http.*;
6 import javax.servlet.*;
7
8 public class OnLineCountListener implements HttpSessionListener,
ServletContextListener,ServletContextAttributeListener
9 {
10  private int count;
11  private ServletContext context = null;
12  
13  public OnLineCountListener()
14  {
15   count=0;
16   //setContext();
17  }
18  //创建一个session时激发
19  public void sessionCreated(HttpSessionEvent se)
20  {
21   count++;
22   setContext(se);
23   
24  }
25  //当一个session失效时激发
26  public void sessionDestroyed(HttpSessionEvent se)
27  {
28   count--;
29   setContext(se);
30  }
31  //设置context的属性，它将激发attributeReplaced或attributeAdded方法
32  public void setContext(HttpSessionEvent se)
33  {
34   se.getSession().getServletContext().
setAttribute("onLine",new Integer(count));
35  }
36   //增加一个新的属性时激发
37  public void attributeAdded(ServletContextAttributeEvent event) {
38 
39  log("attributeAdded('" + event.getName() + "', '" +
40      event.getValue() + "')");
41 
42     }
43    
44    //删除一个新的属性时激发
45     public void attributeRemoved(ServletContextAttributeEvent event) {
46
47  log("attributeRemoved('" + event.getName() + "', '" +
48      event.getValue() + "')");
49 
50     }
51
52  //属性被替代时激发
53     public void attributeReplaced(ServletContextAttributeEvent event) {
54 
55   log("attributeReplaced('" + event.getName() + "', '" +
56       event.getValue() + "')");
57     }
58     //context删除时激发
59      public void contextDestroyed(ServletContextEvent event) {
60 
61   log("contextDestroyed()");
62   this.context = null;
63 
64     }
65 
66     //context初始化时激发
67     public void contextInitialized(ServletContextEvent event) {
68 
69   this.context = event.getServletContext();
70   log("contextInitialized()");
71 
72     }
73     private void log(String message) {
74 
75      System.out.println("ContextListener: " + message);
76     }  
77 }
 

【程序注解】
在OnLineCountListener里，用count代表当前在线的人数，OnLineCountListener将在Web服务器启动时自动执行。当OnLineCountListener构造好后，把count设置为0。每增加一个Session，OnLineCountListener会自动调用sessionCreated(HttpSessionEvent se)方法；每销毁一个Session，OnLineCountListener会自动调用sessionDestroyed(HttpSessionEvent se)方法。当调用sessionCreated(HttpSessionEvent se)方法时，说明又有一个客户在请求，此时使在线的人数（count）加1，并且把count写到ServletContext中。ServletContext的信息是所有客户端共享的，这样，每个客户端都可以读取到当前在线的人数。
 

从作用域范围来说,Servlet的作用域有ServletContext,HttpSession,ServletRequest.

Context范围:

ServletContextListener:
对一个应用进行全局监听.随应用启动而启动,随应用消失而消失主要有两个方法:

contextDestroyed(ServletContextEvent event)

在应用关闭的时候调用

contextInitialized(ServletContextEvent event)

在应用启动的时候调用

这个监听器主要用于一些随着应用启动而要完成的工作,也就是很多人说的我想在容器
启动的时候干..........
一般来说对"全局变量"初始化,如

public void contextInitialized(ServletContextEvent event){
ServletContex sc = event.getServletContext();
sc.setAttribute(name,value);
}

以后你就可以在任何servlet中getServletContext().getAttribute(name);
我最喜欢用它来做守护性工作,就是在contextInitialized(ServletContextEvent event)
方法中实现一个Timer,然后就让应用在每次启动的时候让这个Timer工作:
程序代码：
public void contextInitialized(ServletContextEvent event){
timer = new Timer();
timer.schedule(new TimerTask(){
public void run(){
//do any things
}
},0,时间间隔);
}

有人说Timer只能规定从现在开始的多长时间后,每隔多久做一次事或在什么时间做
一次事,那我想在每月1号或每天12点做一项工作如何做呢?
你只要设一个间隔,然后每次判断一下当时是不是那个时间段就行了啊,比如每月一号做,那你
时间间隔设为天,即24小时一个循环,然后在run方法中判断当时日期new Date().getDate()==1
就行了啊.如果是每天的12点,那你时间间隔设为小时,然后在run中判断new Date().getHour()
==12,再做某事就行了.

ServletContextAttributeListener:

这个监听器主要监听ServletContex对象在setAttribute()和removeAttribute()的事件,注意
也就是一个"全局变量"在被Add(第一次set),replace(对已有的变量重新赋值)和remove的时候.
分别调用下面三个方法:
public void attributeAdded(ServletContextAttributeEvent scab)这个方法不仅可以知道
哪些全局变量被加进来,而且可获取容器在启动时自动设置了哪些context变量:
程序代码：
public void attributeAdded(ServletContextAttributeEvent scab){
System.out.println(scab.getName());
}
public void attributeRemoved(ServletContextAttributeEvent scab)

public void attributeReplaced(ServletContextAttributeEvent scab)

Session范围:
HttpSessionListener:
这个监听器主要监听一个Session对象被生成和销毁时发生的事件.对应有两个方法:
程序代码：
public void sessionCreated(HttpSessionEvent se)

public void sessionDestroyed(HttpSessionEvent se)

一般来说,一个session对象被create时,可以说明有一个新客端进入.可以用来粗略统计在线人
数,注意这不是精确的,因为这个客户端可能立即就关闭了,但sessionDestroyed方法却会按一定
的策略很久以后才会发生.

HttpSessionAttributeListener:
和ServletContextAttributeListener一样,它监听一个session对象的Attribut被Add(一个特定
名称的Attribute每一次被设置),replace(已有名称的Attribute的值被重设)和remove时的事件.
对就的有三个方法.
程序代码：
public void attributeAdded(HttpSessionBindingEvent se)

public void attributeRemoved(HttpSessionBindingEvent se)

public void attributeReplaced(HttpSessionBindingEvent se)

上面的几个监听器的方法,都是在监听应用逻辑中servlet逻辑中发生了什么事,一般的来说.
我们只要完成逻辑功能,比如session.setAttribute("aaa","111");我只要把一个名为aaa的变量
放在session中以便以后我能获取它,我并不关心当session.setAttribute("aaa","111");发生时
我还要干什么.(当然有些时候要利用的),但对于下面这个监听器,你应该好好发解一下:

HttpSessionBindingListener:
上面的监听器都是作为一个独立的Listener在容器中控制事件的.而HttpSessionBindingListener
对在一对象中监听该对象的状态,实现了该接口的对象如果被作为value被add到一个session中或从
session中remove,它就会知道自己已经作为一个session对象或已经从session删除,这对于一些非
纯JAVA对象,生命周期长于session的对象,以及其它需要释放资源或改变状态的对象非常重要.
比如:
session.setAttribute("abcd","1111");
以后session.removeAttribute("abcd");因为abcd是一个字符中,你从session中remove后,它就会
自动被垃圾回收器回收,而如果是一个connection:(只是举例,你千万不要加connection往session
中加入)
程序代码：
session.setAttribute("abcd",conn);

以后session.removeAttribute("abcd");这时这个conn被从session中remove了,你已经无法获取它
的句柄,所以你根本没法关闭它.而在没有remove之前你根本不知道什么时候要被remove,你又无法
close(),那么这个connection对象就死了.另外还有一些对象可以在被加入一个session时要锁定
还要被remove时要解锁,应因你在程序中无法判断什么时候被remove(),add还好操作,我可以先加锁
再add,但remove就后你就找不到它的句柄了,根本没法解锁,所以这些操作只能在对象自身中实现.
也就是在对象被add时或remove时通知对象自己回调相应的方法:
程序代码：
MyConn extends Connection implements HttpSessionBindingListener{
public void valueBound(HttpSessionBindingEvent se){
this.initXXX();
}
public void valueUnbound(HttpSessionBindingEvent se){

this.close();
}
}

session.setAttribute("aaa",new MyConn());
这时如果调用session.removeAttribute("aaa"),则触发valueUnbound方法,就会自动关闭自己.
而其它的需要改变状态的对象了是一样.

The Life Cycles of Enterprise Beans

An enterprise bean goes through various stages during its lifetime, or life cycle. Each type of enterprise bean--session, entity, or message-driven--has a different life cycle.

The descriptions that follow refer to methods that are explained along with the code examples in the next two chapters. If you are new to enterprise beans, you should skip this section and try out the code examples first.

The Life Cycle of a Stateful Session Bean

Figure 3-3 illustrates the stages that a session bean passes through during its lifetime. The client initiates the life cycle by invoking the create method. The EJB container instantiates the bean and then invokes the setSessionContext and ejbCreate methods in the session bean. The bean is now ready to have its business methods invoked.

 

Figure 3-3 Life Cycle of a Stateful Session Bean

While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. (Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) The EJB container invokes the bean's ejbPassivate method immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, moving it back to the ready stage, and then calls the bean's ejbActivate method.

At the end of the life cycle, the client invokes the remove method and the EJB container calls the bean's ejbRemove method. The bean's instance is ready for garbage collection.

Your code controls the invocation of only two life-cycle methods--the create and remove methods in the client. All other methods in Figure 3-3 are invoked by the EJB container. The ejbCreate method, for example, is inside the bean class, allowing you to perform certain operations right after the bean is instantiated. For instance, you may wish to connect to a database in the ejbCreate method. See Chapter 16 for more information.

The Life Cycle of a Stateless Session Bean

Because a stateless session bean is never passivated, its life cycle has just two stages: nonexistent and ready for the invocation of business methods. Figure 3-4 illustrates the stages of a stateless session bean.

 

Figure 3-4 Life Cycle of a Stateless Session Bean

The Life Cycle of an Entity Bean

Figure 3-5 shows the stages that an entity bean passes through during its lifetime. After the EJB container creates the instance, it calls the setEntityContext method of the entity bean class. The setEntityContext method passes the entity context to the bean.

After instantiation, the entity bean moves to a pool of available instances. While in the pooled stage, the instance is not associated with any particular EJB object identity. All instances in the pool are identical. The EJB container assigns an identity to an instance when moving it to the ready stage.

There are two paths from the pooled stage to the ready stage. On the first path, the client invokes the create method, causing the EJB container to call the ejbCreate and ejbPostCreate methods. On the second path, the EJB container invokes the ejbActivate method. While in the ready stage, an entity bean's business methods may be invoked.

There are also two paths from the ready stage to the pooled stage. First, a client may invoke the remove method, which causes the EJB container to call the ejbRemove method. Second, the EJB container may invoke the ejbPassivate method.

 

Figure 3-5 Life Cycle of an Entity Bean

At the end of the life cycle, the EJB container removes the instance from the pool and invokes the unsetEntityContext method.

In the pooled state, an instance is not associated with any particular EJB object identity. With bean-managed persistence, when the EJB container moves an instance from the pooled state to the ready state, it does not automatically set the primary key. Therefore, the ejbCreate and ejbActivate methods must assign a value to the primary key. If the primary key is incorrect, the ejbLoad and ejbStore methods cannot synchronize the instance variables with the database. In the section The SavingsAccountEJB Example, the ejbCreate method assigns the primary key from one of the input parameters. The ejbActivate method sets the primary key (id) as follows:

id = (String)context.getPrimaryKey();
 

In the pooled state, the values of the instance variables are not needed. You can make these instance variables eligible for garbage collection by setting them to null in the ejbPasssivate method.

The Life Cycle of a Message-Driven Bean

Figure 3-6 illustrates the stages in the life cycle of a message-driven bean.

The EJB container usually creates a pool of message-driven bean instances. For each instance, the EJB container instantiates the bean and performs these tasks:

1. It calls the setMessageDrivenContext method to pass the context object to the instance.
2. It calls the instance's ejbCreate method.

 

Figure 3-6 Life Cycle of a Message-Driven Bean

Like a stateless session bean, a message-driven bean is never passivated, and it has only two states: nonexistent and ready to receive messages.

At the end of the life cycle, the container calls the ejbRemove method. The bean's instance is then ready for garbage collection.

2． 依赖容器的参数化事务管理
通过容器提供的集约式参数化事务机制，实现事务的外部管理，如EJB 中的事务管理模式。
 容器管理的参数化事务为程序开发提供了相当的灵活性，同时因为将事务委托给容器进行管理，
应用逻辑中无需再编写事务代码，大大节省了代码量（特别是针对需要同时操作多个事务资源的应用），从而提高了生产率。

Connection Pool

ejbPassivate:当一个bean实例被客户引用，并执行一个业务方法后，容器会自动读取bean的实例字段，
然后通过容器与数据库发生关系，保存改变的数据，执行完毕后bean被钝化，并调用ejbpassviate()方法通知bean。

ejbactivate：当客户过一端时间又调用这个bean的某业务方法时，被钝化的bean又重新的激活，但是并不是马上执行这个业务方法，
而是由ejb对象首先调用ejbactivate()方法通知bean，bean实例要激活，然后从数据库中提取数据，并自动将数据值映射到bean实例，
然后调用ejbload()方法，实例被再一次初始化，最后才开始执行要执行的业务方法。

Stateful Session Bean 
以 Stateful Session Bean  为例：其 Cache 大小决定了内存中可以同时存在的 Bean 实例的数量，根据 MRU 或 NRU 算法，实例在激活和去激活状态之间迁移，激活机制是当客户端调用某个 EJB 实例业务方法时，如果对应 EJB Object 发现自己没有绑定对应的 Bean 实例则从其去激活 Bean 存储中（通过序列化机制存储实例）回复（激活）此实例。状态变迁前会调用对应的 ejbActive 和 ejbPassivate 方法。

会话 bean 和实体 bean 可能的属性值包括：

• Required —— bean 必须始终运行在事务中。如果客户端已经启动一个事务，则 bean 将加入到事务中。如果客户端还没有启动事务，那么 EJB 容器将启动一个新事务。当需要 bean 始终运行在事务中时，请使用该属性。
• RequiresNew —— bean 始终启动一个新的事务。如果客户端已经启动一个事务，则挂起现有事务，直到新事务已提交或中止。在新事务完成之后，现有事务将继续。当需要 bean 作为一个单独的工作单元运行并展示所有的 ACID 属性时，请使用该属性。
• Supports —— 如果客户端启动一个事务，则 bean 将加入到事务中。但是，如果事务不存在，EJB 容器不会启动一个新事务。要在企业 bean 上执行非任务关键型操作时，请使用该属性。
• Mandatory —— 在调用 bean 时客户端必须启动一个事务。这不会创建一个新的事务。在调用 bean 时，如果没有事务已经启动，则将抛出一个异常。当 bean 是某一较大系统的一部分时，请使用该属性。通常可能由第三方负责启动事务。对用户而言，这是一个安全选项，因为它可以确保 bean 将成为事务的一部分。
• NotSupported —— 在事务中不能调用 bean。如果客户端已经启动一个事务，则挂起现有事务，直到 bean 的方法完成。在完成上述方法之后，现有事务将继续。如果客户端没有启动事务，则不会创建一个新事务。在不需要 bean 展示任何 ACID 属性（比如类似报表的非系统关键型操作）时，请使用该属性。
• Never —— 如果客户端启动一个事务，则 bean 将抛出一个异常。在您可能永远都不想让您的 bean 参与到事务中的情况下，请使用该属性。

回页首

消息驱动 bean 的事务属性

只有两种消息驱动 bean 消息监听器方法使用的事务属性：

• NotSupported —— bean 不能参与到事务中。如果客户端启动一个事务，那么现有事务将挂起，直到 bean 的方法完成为止。在完成上述方法之后，现有事务将继续。如果客户端没有启动事务，则不会创建一个新的事务。
• Required —— bean 必须始终运行在事务中。如果客户端已经启动事务，则 bean 将加入到事务中。如果客户端没有启动事务，则 EJB 容器将启动一个新事务。

在为企业 bean 方法确定正确事务属性之后，就可以配置 EJB 部署描述符了。

回页首

配置 EJB 部署描述符

对于每个企业 bean，都要在部署描述符中配置事务的下列两个部分：

• 在 EJB 部署描述符中使用 <transaction-type> 元素指定 bean 使用的是容器管理的事务还是 bean 管理的事务。可能的值是 container 或 bean。由于实体 bean 必须使用容器管理的事务，这只对会话 bean 和消息驱动 bean 是必需的。
• 对于容器管理的事务，您可以为企业 bean 的方法随意指定事务属性。在 EJB 部署描述符中的 <container-transaction> 部分指定它。清单 1 中显示了每种方法的通用格式。

<method>
            <ejb-name>EJBNAME</ejb-name>
            <method-name>METHODNAME</method-name>
            <trans-attribute>TRANSATTRIBUTE</trans-attribute>
            </method>
            

TRANSATTRIBUTE 可能的值有：

• NotSupported
• Required
• Supports
• RequiresNew
• Mandatory
• Never

也可以对企业 bean 的所有方法指定事务属性。对 <method-name> 属性使用 *。

清单 2 显示了为容器管理的企业 bean 指定事务属性的示例。除了为 updateClaimNumber 方法分配 Mandatory 属性以外，ClaimRecord企业 bean 为所有方法都分配了 Required 属性。Coverage bean 对所有方法指派 RequiresNew 属性。

<ejb-jar>
            ...
            <assembly-descriptor>
            ...
            <container-transaction>
            <method>
            <ejb-name>ClaimRecord</ejb-name>
            <method-name>*</method-name>
            </method>
            <trans-attribute>Required</trans-attribute>
            </container-transaction>
            <container-transaction>
            <method>
            <ejb-name>ClaimRecord</ejb-name>
            <method-name>updateClaimNumber</methodname>
            </method>
            <trans-attribute>Mandatory</trans-attribute>
            </container-transaction>
            <container-transaction>
            <method>
            <ejb-name>Coverage</ejb-name>
            <method-name>*</method-name>
            </method>
            <trans-attribute>RequiresNew</trans-attribute>
            </container-transaction>
            ...
            </assembly-descriptor>
            ...
            </ejb-jar>
            

1、web.xml
  i.error-code：错误码 
  <error-page>  
      <error-code>404</error-code> 
      <location>/404.jsp</location>
  </error-page>
  
  ii.exception-type
当servlet执行时，可能产生许多异常。而当异常产生时，Web容器将产生一个包含A Servlet Has Occurred消息的缺省页。但是，用户也可返回一个容器，该容器应包含为给定异常指定的错误页。
  <error-page>  
      <exception-type>org.sprngside.bookstore.UserNotFound</exception-type>  
      <location>/userNotFound.jsp</location>
  </error-page>
  
  
2、jsp
 <@ errorPage="error.jsp">

3、Spring MVC里的异常控制
   spring-mvc可在xxx-serverlet.xml里定义default和 按Excepiton类型影射的错误页面,
   和Servlet规范比,主要作了Spring特色的JSP路径转向和日志记录.参见bookstore-servlet.xml
  
 <bean id="exceptionResolver" class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
      <property name="defaultErrorView" value="/error.jsp"/>
      <property name="exceptionMappings">
           <props>               
                <prop key="org.springside.framework.base.BusinessException">/businessError.jsp</prop>
            </props>       
       </property>   
 </bean>

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
  error.jsp会同时处理jsp,servlet,和spring抛过来的异常
  
  jsp的异常在exception 变量中.（要指定<%@ page isErrorPage="true" %>）
  
  spring的异常在(Exception) request.getAttribute("exception")
  
  servlet的异常在(Exception)request.getAttribute("javax.servlet.error.exception")
  
  使用 (String) request.getAttribute("javax.servlet.error.request_uri")获得 request_uri
  使用 logger.error(exception.getMessage(), exception); 记录整个异常栈

   
  · javax.servlet.error.exception：实际的异常掷出的Throwable对象
  · javax.servlet.error.request_uri：导致问题产生的资源的URI字符串对象
  · javax.servlet.error.status_code：错误类型的整形值
  · javax.servlet.error.exception_type：产生错误的异常类的实例
  · javax.servlet.error.message：异常信息字符串
  
  

error.jsp 完整的代码

<%@ page contentType="text/html;charset=UTF-8" isErrorPage="true" %>
<%@ page import="org.apache.commons.logging.LogFactory" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<html>
<head>
    <title>Error Page</title>
    <script src="<c:url value="/scripts/prototype.js"/>" type="text/javascript"></script>
    <script language="javascript">
        function showDetail()
        {
            $('detail_error_msg').toggle();
        }
    </script>
</head>

<body>

<div id="content">
    <%
        //Exception from JSP didn't log yet ,should log it here.
        String requestUri = (String) request.getAttribute("javax.servlet.error.request_uri");
        LogFactory.getLog(requestUri).error(exception.getMessage(), exception);
    %>

    <h3>System Runtime Error: <br><%=exception.getMessage()%></h3><br>

    <button onclick="history.back();">Back</button><br>

    <p><a href="#" onclick="showDetail();">Administrator click here to get the detail.</a></p>

    <div id="detail_error_msg" style="display:none">
        <pre><%exception.printStackTrace(new java.io.PrintWriter(out));%></pre>
    </div>
</div>
</body>
</html> 

referer是浏览器在用户提交请求当前页面中的一个链接时,将当前页面的URL放在头域中提交给服务端的,
如当前页面为a.html,它里面有一个b.html的链接,当用户要访问b.html时浏览器就会把a.html作为referer发给服务端.

errorpage 根本不是用户去访问的,绝对大多数errorPage是forward,由服务端直接调用http连接访问errorpage将结果发给用户.
用户根本没有访问errorPage.

对于location="aaa.jsp"这样用js访问没有referer,是因为当执行location="aaa.jsp"时,当前页面的URL已经是aaa.jsp,
真的要取上一级当然可以从history中取到发给服务端,但那已经不是Referer的本意了..可以以如下代码来代替:
function jump(url){
    var e = document.createElement("a");
    e.href = url;
    document.body.appendChild(e);
    e.click();
}

//JAVA 中
String currentURL = request.getRequestURL().toString();
String preURL = request.getHeader("referer");

if (currentURL.equals(preURL) ) {
 return new RedirectingActionForward(preURL);
} else {
 return new RedirectingActionForward(currentURL)
}

（1）工程路径

（2）类路径
相对于WEB-INF/classes而言的

--->>>jsp中的路径
/egl/pages/logistics/trans_provide_info.jsp

egl是工程名，在tomcat的config中配置的
<Context path="/egl" docBase ="E:/work/EGL/public/dev/web" reloadable="true">
    <Logger className="org.apache.catalina.logger.FileLogger"
            prefix="egl_log." suffix=".txt" timestamp="true"/>
</Context>
后面的pages/logistics/trans_provide_info.jsp就是E:/work/EGL/public/dev/web下面的文件

--->>>action的路径
/egl/logistics/trans_provide_info.do

egl是工程名,它查找WEB-INF/classes下的trans_provide_info对应的class，中间/logistics是namespace
<package name="logistics" extends="webwork-default" namespace="/logistics">
   <default-interceptor-ref name="myDefaultWebStack"/>

   <action name="trans_provide_info" class="j1.logistics.tp.action.TransProvideAction">
   <result name="success" type="chain">
        <param name="actionName">trans_provide_list</param>
        <param name="namespace">/logistics</param>
    </result>             
    </action>
        ......
/egl/logistics/trans_provide_info.do ＝/egl/WEB-INF/classes/logistics/trans_provide_info.do 

关于taglib
（1）在web.xml中定义一个taglib

<%@ taglib prefix="ww" uri="webwork"%>//uri不符合*.tld里面的uri，但是在web.xml定义了
<jsp-config>
    <taglib>
        <taglib-uri>webwork</taglib-uri>
        <taglib-location>/WEB-INF/taglib.tld</taglib-location>
    </taglib>
    <jsp-property-group>
        <url-pattern>*.jsp</url-pattern>
        <page-encoding>gb2312</page-encoding>
    </jsp-property-group>
</jsp-config>

（2）web.xml中没有定义，如果uri符合*.tld里面的uri，默认读取jar/META-INF

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
读取standard.jar/META-INF/c.tld

【注】prefix可以随便定义，只是一个前缀。

<jsp-config>
        <taglib>
            <taglib-uri>/WEB-INF/c.tld</taglib-uri>
            <taglib-location>/WEB-INF/c.tld</taglib-location>
        </taglib>
        <jsp-property-group>
            <url-pattern>*.jsp</url-pattern>
            <page-encoding>UTF-8</page-encoding>
        </jsp-property-group>
    </jsp-config>


<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

● c:set
语法1：将 value的值储存至范围为scope的 varName 变量之中
<c:set value="value" var="varName" [scope="{ page|request|session|application }"]/>
语法2：将本体内容的数据储存至范围为scope的 varName 变量之中
<c:set var="varName" [scope="{ page|request|session|application }"]>… 本体内容</c:set>
语法3：将 value的值储存至 target 对象的属性中
<c:set value="value" target="target" property="propertyName" />
语法4：将本体内容的数据储存至 target 对象的属性中
<c:set target="target" property="propertyName">… 本体内容</c:set>

● <c:remove>
<c:remove var="varName" [scope="{ page|request|session|application }"] />

● <c:catch>
<c:catch [var="varName"] >… 欲抓取错误的部分</c:catch>

● <c:if>
语法1：没有本体内容(body)
<c:if test="testCondition" var="varName" [scope="{page|request|session|application}"]/>
语法2：有本体内容
<c:if test="testCondition" [var="varName"] [scope="{page|request|session|application}"]>本体内容</c:if>

● <c:choose>
<c:choose>
 ：
 <c:when>
 </c:when>
 ：
 <c:otherwise>
 </c:otherwise>
 ：
</c:choose>

● <c:when>
<c:when test="testCondition" >本体内容</c:when>

● <c:otherwise>
<c:otherwise>本体内容</c:otherwise>

(2)迭代操作
● <c:forEach>
语法1：迭代一集合对象之所有成员
<c:forEach [var="varName"] items="collection" [varStatus="varStatusName"]
[begin="begin"] [end="end"] [step="step"]>
本体内容
<
/c:forEach>
语法2：迭代指定的次数
<c:forEach [var="varName"] [varStatus="varStatusName"] begin="begin" end="end" [step="step"]>
本体内容
</c:forEach>

(3)URL操作

(1) Expression Language
JSP 2.0 之后，正式将EL 纳入JSP 的标准语法。EL 主要的功用在于简化JSP 的语法，方便Web
开发人员的使用。例如:count：${param.count + 5}

(2) 新增Simple Tag 和Tag File

( 3) web.xml 新增<jsp-config>元素

2  EL 变量
${pageScope.username}...


3 自动转变类型
${param.count + 20}

4 EL 隐含对象
         隐含对象                   类 型                                              说 明
     PageContext       javax.servlet.ServletContext       表示此JSP 的PageContext
     PageScope          java.util.Map                       取得Page 范围的属性名称所对应的值
     RequestScope     java.util.Map                   取得Request 范围的属性名称所对应的值
     sessionScope      java.util.Map                    取得Session 范围的属性名称所对应的值
     applicationScope java.util.Map            取得Application 范围的属性名称所对应的值
     param                  java.util.Map        如同ServletRequest.getParameter(String name)。
                                                                回传String 类型的值

   paramValues         java.util.Map       如同ServletRequest.getParameterValues(String
                                                               name)。回传String []类型的值
   header                    java.util.Map      如同ServletRequest.getHeader(String name)。
                                                              回传String 类型的值
   headerValues        java.util.Map       如同ServletRequest.getHeaders(String name)。
                                                              回传String []类型的值
  cookie                    java.util.Map       如同HttpServletRequest.getCookies( )
  initParam               java.util.Map       如同ServletContext.getInitParameter(String
                                                               name)。回传String 类型的值



5 EL 算术运算符/关系运算符/逻辑运算符

6 其他运算符
(1) Empty 运算符
(2) 条件运算符
(3) ( ) 括号运算符

[Receiver]
   QueueSession queueSession = queueConnection.createQueueSession(transacted, acknowledgementMode);
   QueueReceiver queueReceiver = queueSession.createReceiver(queue);   

   queueReceiver.setMessageListener(msgRcvr);
   
   //msgRcvr-->MessageListener的onMessage方法
   public synchronized void  onMessage(Message message) {
   if (message instanceof TextMessage) {
        TextMessage textMessage = (TextMessage) message;
    try {
         System.out.println("Message content is:" + textMessage.getText());
    }catch (JMSException e) {
         e.printStackTrace();
    }
   }
  }

[Receiver]
   public synchronized void  onMessage(Message message) {
   if (message instanceof TextMessage) {
     TextMessage oldMessage = (TextMessage) message; 
              
     Queue tempQueue = (Queue)oldMessage.getJMSReplyTo();
     queueSender = queueSession.createSender(tempQueue);
     
     TextMessage newMessage = queueSession.createTextMessage();  
     newMessage.setJMSCorrelationID(oldMessage.getJMSCorrelationID());
     newMessage.setText("test");
     
     queueSender.send(newMessage);

  }

【注】
      1)JMSCorrelationID 比较关键，只是一个身分标识，上面有3个地方使用
      2)Template 用于临时template中，她的设置影响 cID
如果String cID = (Math.random()*10) + ""; 抛出“Byte quota exceeded for...”于template 设置有关

Servlet 2.4 的新功能

1. web.xml DTD 改用XML Schema, 主要加强两项功能：
(1) 元素可不依照顺序设定；
(2) 更强大的验证机制。
   a. 可检查元素的值是否为合法的值。例如：<filter-mapping>的<dispatcher>元素，其值只
能为REQUEST、FORWARD、INCLUDE 和ERROR
   b.可检查如Servlet、Filter 或EJB-ref 等等元素的名称是否惟一
   c.可检查元素值是否为合法文字字符或数字字符

2.新增Filter 四种设定；
filter-mapping-->dispatcher-->
 四种设定为：REQUEST、FORWARD、INCLUDE 和ERROR。
FORWARD: RequestDispatcher.forward()   REQUEST: 由客户端发出请求
INCLUDE: RequestDispatcher.include()   ERROR:

3. 新增Request Listener、Event 和Request Attribute Listener、Event
 
4. Servlet 2.4 其他较显著的变更如：
 a. 
    取消SingleThreadModel接口。当Servlet实现SingleThreadModel 接口时，它能确保同时间内，只能有一个thread 执行此Servlet。
 b.
<welcome-file-list>可以为Servlet。
 <servlet>
  <servlet-name>Index</servlet-name>
  <servlet-class>tw.com.javaworld.IndexServlet</servlet-class>
 </servlet>
 ......
 <welcome-file-list>
  <welcome-file>Index</welcome-file>
 </welcome-file-list>
 c.
   ServletRequest 接口新增一些方法，如：
  public String getLocalName( );
  public String getLocalAddr( );
  public int getLocalPort( );
  public int getRemotePort( );

一、Cache介绍
Cache是一种用于提高系统响应速度、改善系统运行性能的技术。尤其是在Web应用中，通过缓存页面的输出结果，可以很显著的改善系统运行性能。

例如：电子商务中关于送货区域，统计报表
1.1 问题的共同点
1、被处理的内容短时间不变，所以短时间内可以作为静态内容进行处理
2、在一个不太长的时间内，被处理内容可能或者必定产生变化，所以必须将他们作为动态内容进行处理
3、在合理的时间区段内可以忽略被处理内容变化后带来的影响
4、对这些内容的处理动作比较消耗系统性能，影响系统响应时间

1.2 解决方法
1、缓存信息
      当上述的基础数据或者统计报表第一次被访问时，被处理的内容被当作动态信息，基础数库从数据库中获得，统计报表也会被生成符合要求的图形、文件，然后这些信息都会被放入缓存信息中。

2、响应信息由缓存提供
      当上述的基础数据或者统计报表继续被访问时，系统将会首先检查缓存信息中是否有对应的内容和我们设定的缓存规则，如果符合缓存信息存在而且符合缓存规则，给出的响应将来自于缓存信息，如果没有或者缓存信息已经不符合设定的要求，系统将重复上一步的动作。

很显然，上面的步骤2中，多数情况下，当用户请求到达时，被处理的内容将来自于缓存，所以大大的减少了与数据库的交互，或者不再需要为每个请求都生成一次报表图形或者文件，这部分工作的减少对于降低系统性能消耗、提高系统稳定性和并发处理能力是非常有益的。

二、OSCache介绍
OSCache中按照缓存范围的不同分为两种不同的方式：一种是缓存JSP页面中部分或者全部内容，一种是基于整个页面文件的缓存。

2.1 Cache-OSCache提供的缓存JSP页面中部分或者全部内容标签

这是OSCache提供的标签库中最重要的一个标签，包括在标签中的内容将应用缓存机制进行处理，处理的方式将取决于编程者对cache标签属性的设置。

第一次请求到达时，标签中的内容被处理并且缓存起来，当下一个请求到达时，缓存系统会检查这部分内容的缓存是否已经失效，主要是以下几项：

1. 缓存时间超过了cache标签设置的time或者duration属性规定的超时时间
2. cron属性规定的时间比缓存信息的开始时间更晚
3. 标签中缓存的内容在缓存后又被重新刷新过
4. 其他缓存超期设定
如果符合上面四项中的任何一项，被缓存的内容视为已经失效，这时被缓存的内容将被重新处理并且返回处理过后的信息，如果被缓存的内容没有失效，那么返回给用户的将是缓存中的信息。

cache标签的属性说明:

key - 标识缓存内容的关键词。在指定的作用范围内必须是唯一的。默认的key是被访问页面的URI和后面的请求字符串。 你可以在同一个页面中使用很多cache标签而不指定他的key属性，这种情况下系统使用该页面的URI和后面的请求字符串，另外再自动给这些key增加一个索引值来区分这些缓存内容。但是不推荐采用这样的方式。

scope - 缓存发生作用的范围，可以是application或者session
time - 缓存内容的时间段，单位是秒，默认是3600秒，也就是一个小时，如果设定一个负值，那么这部分被缓存的内容将永远不过期。
duration - 指定缓存内容失效的时间，是相对time的另一个选择，可以使用简单日期格式或符合USO-8601的日期格式。如：duration='PT5M' duration='5s'等
refresh - false 或者true。如果refresh属性设置为true，不管其他的属性是否符合条件，这部分被缓存的内容都将被更新，这给编程者一种选择，决定什么时候必须刷新。
mode - 如果编程者不希望被缓存的内容增加到给用户的响应中，可以设置mode属性为"silent"

cron- Cron表达式包括5个字段分别为Minute,Hour,DOM(Day Of Month),Month,DOW(Day Of Week)。
     他们顺序地对应了5个位置。当某个位置上的值为*时,表示该位置上的任意时间。
       另外还提供了指定时间的操作符号"-"，","，"/"，他们分别表示一段时间范围，具体的时间，以及递增的时间段。
       下面是几个例子说明一下Cron表达式的基本应用，有兴趣的也可以查看下OSCache的文档。

2.2 用CashFilter实现页面级缓存

在OSCache组件中提供了一个CacheFilter用于实现页面级的缓存，主要用于对web应用中的某些动态页面进行缓存，尤其是那些需要生成pdf格式文件/报表、图片文件等的页面，不仅减少了数据库的交互、减少数据库服务器的压力，而且对于减少web服务器的性能消耗有很显著的效果。

这种功能的实现是通过在web.xml中进行配置来决定缓存哪一个或者一组页面，而且还可以设置缓存的相关属性，这种基于配置文件的实现方式对于J2EE来说应该是一种标准的实现方式了。

<filter>
      <filter-name>CacheFilter</filter-name>
      <filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class>
      <init-param>
         <param-name>time</param-name>
         <param-value>600</param-value>
      </init-param>
      <init-param>
         <param-name>scope</param-name>
         <param-value>session</param-value>
      </init-param>
</filter>
<filter-mapping>
<filter-name>CacheFilter</filter-name>
<!-对/testContent.jsp页面内容进行缓存-->
      <url-pattern>/testContent.jsp</url-pattern>
<!-对所有jsp页面内容进行缓存-->
      <url-pattern>*.jsp</url-pattern>
</filter-mapping>

参考：
1. 应用OSCache提升J2EE系统运行性能
2、oscache源代码