Web

六个方法解决应用程序中死锁现象的出现 在应用程序中就可以采用下面的一些方法来避免死锁: (1) 合理安排表访问顺序。 (2) 在事务中尽量避免用户干预，尽量使一个事务处理的任务少些, 保持事务简短并在一个批处理中。 (3) 数据访问时域离散法, 数据访问时域离散法是指在客户机/服务器结构中，采取各种控制手段控制对数据库或数据库中的对象访问时间段。主要通过以下方式实现: 合理安排后台事务的执行时间，采用工作流对后台事务进行统一管理。工作流在管理任务时，一方面限制同一类任务的线程数 (往往限制为1个) ，防止资源过多占用; 另一方面合理安排不同任务执行时序、时间，尽量避免多个后台任务同时执行，另外， 避免在前台交易高峰时间运行后台任务。 (4) 数据存储空间离散法。数据存储空间离散法是指采取各种手段，将逻辑上在一个表中的数据分散到若干离散的空间上去，以便改善对表的访问性能。主要通过以下方法实现: 第一，将大表按行或列分解为若干小表; 第二，按不同的用户群分解。 (5) 使用尽可能低的隔离性级别。隔离性级别是指为保证数据库数据的完整性和一致性而使多用户事务隔离的程度，SQL92定义了4种隔离性级别: 未提交读、提交读、可重复读和可串行。如果选择过高的隔离性级别，如可串行，虽然系统可以因实现更好隔离性而更大程度上保证数据的完整性和一致性，但各事务间冲突而死锁的机会大大增加，大大影响了系统性能。 (6) 使用绑定连接, 绑定连接允许两个或多个事务连接共享事务和锁，而且任何一个事务连接要申请锁如同另外一个事务要申请锁一样，因此可以允许这些事务共享数据而不会有加锁的冲突。

死锁 (Deadlocks) deadlocks (死锁) 所谓死锁: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程. 由于资源占用是互斥的，当某个进程提出申请资源后，使得有关进程在无外力协助下，永远分配不到必需的资源而无法继续运行，这就产生了一种特殊现象死锁。 一种情形，此时执行程序中两个或多个线程发生永久堵塞 (等待) ，每个线程都在等待被其他线程占用并堵塞了的资源。例如，如果线程A锁住了记录1并等待记录2，而线程B锁住了记录2并等待记录1，这样两个线程就发生了死锁现象。 计算机系统中,如果系统的资源分配策略不当，更常见的可能是程序员写的程序有错误等，则会导致进程因竞争资源不当而产生死锁的现象。 产生死锁的原因主要是: (1) 因为系统资源不足。 (2) 进程运行推进的顺序不合适。 (3) 资源分配不当等。 如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则 就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。 产生死锁的四个必要条件: (1) 互斥条件: 一个资源每次只能被一个进程使用。 (2) 请求与保持条件: 一个进程因请求资源而阻塞时，对已获得的资源保持不放。 (3) 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。 (4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。 这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之 一不满足，就不会发生死锁。 死锁的解除与预防: 理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态 的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。

webkit WebKit 是一个开源的浏览器引擎，与之相对应的引擎有Gecko (Mozilla Firefox 等使用) 和Trident (也称MSHTML，IE 使用) 。同时WebKit 也是苹果Mac OS X 系统引擎框架版本的名称，主要用于Safari，Dashboard，Mail 和其他一些Mac OS X 程序。WebKit 前身是 KDE 小组的 KHTML，WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎来自于 KDE 的 KHTML 和 KJS，当年苹果比较了 Gecko 和 KHTML 后，仍然选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。Apple将 KHTML 发扬光大，推出了装备 KHTML 改进型 WebKit 引擎的浏览器 Safari。 WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎，均是从KDE的KHTML及KJS引擎衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统的开发。所以Webkit也是自由软件，同时开放源代码。 WebKit的优势在于高效稳定，兼容性好，且源码结构清晰，易于维护。 尽管Webkit内核是个非常好的网页解析机制，但是由于以往微软把IE捆绑在Windows里(同样的Webkit内核的Safari捆绑在Apple产品里，Google Chrome捆绑在Google产品里)，导致许多网站都是按照IE来架设的，很多网站不兼容Webkit内核，比如登录界面、网银等网页均不可使用Webkit内核。目前几乎所有网站和网银已经逐渐支持WebKit，未来可能将取代IE内核的浏览器。 WebKit 内核在手机上的应用也十分广泛，例如 Google 的手机 Android、 Apple 的 iPhone, Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。 WebKit是开源的Web浏览器引擎，苹果的Safari、谷歌的Chrome浏览器都是基于这个框架来开发的。WebKit 还支持移动设备和手机，包括iPhone和Android手机都是使用WebKit做为浏览器的核心。 ...

浏览器加载和渲染网页的过程 关于网页加载和渲染的过程，在网络上的讨论并不多。可能是因为这个过程比较复杂，而且浏览器执行的速度太快，目前还没有发现什么比较好的工具可以清楚的看到浏览器解析网页的每一个过程。通过firedug和httpWatch可以看到浏览器的http请求，但是对于浏览器如何paint和flow处理html元素，我们仍然是不得而知。“flow"这个词借鉴于reflow，表示浏览器第一次加载网页的过程。在网络上搜索了一下，学习如下。 关于浏览器加载网页过程的有趣视频 可以参见: http://www.aoao.org.cn/blog/2008/05/reflow/ (形象化的reflow) 。这个视频展现了网页加载的过程，看着比较有趣。要是可以更加形象化，就更好了，可以帮助我们书写更好的提高网页加载速度的代码。 浏览器内核 不同的浏览器内核，对于网页的解析过程肯定也不尽相同。http://www.mac52ipod.cn/post/Trident-Gecko-WebKit-Presto.php 一文对各种浏览器的页面渲染引擎进行了简介。目前主要有基于 (1) Trident页面渲染引擎 –> IE系列浏览器； (2) Gecko页面渲染引擎 –> Mozilla Firefox； (3) KHTML页面渲染引擎或WebKit框架 –> Safafi和Google Chrome； (4) Presto页面渲染引擎 –> Opera 详细的介绍可以参见原文。 浏览器解析网页的过程 http://hi.baidu.com/seosky/blog/item/78d3394c130f86ffd72afc56.html 浏览器加载和渲染原理分析一文中通过一定的方法，推断了浏览器加载解析网页的顺序大致如下: IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的； 在渲染到页面的某一部分时，其上面的所有部分都已经下载完成 (并不是说所有相关联的元素都已经下载完) ； 在下载过程中，如果遇到某一标签是嵌入文件，并且文件是具有语义解释性的 (例如: JS脚本，CSS样式) ，那么此时IE的下载过程会启用单独连接进行下载，并且在下载后进行解析，解析 (JS、CSS中如有重定义，后定义函数将覆盖前定义函数) 过程中，停止页面所有往下元素的下载； 样式表文件比较特殊，在其下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素 (含以前已经渲染的) 重新进行样式渲染。并以此方式一直渲染下去，直到整个页面渲染完成。 当然这是一个推断的过程。 借助Google PageSpeed和Yahoo YSlow分析网页加载 通过这两个工具，测试网页加载过程，可以得到一些提高网页加载速度的建议。使用Google PageSpeed对Google首页进行分析，可以得到建议: (1) 压缩javascript和CSS； (2) 合并外部javascript和CSS； (3) 减少DNS寻址时间；这条与将图片分散到不同的域名存储这条折中处理； (4) 使用缓存； (5) 尽量避免CSS表达式； (6) 为图片增加宽度和高度属性； (7) 将css放在网页头部，合理放置js的位置。 同时，利用YSlow对google首页进行分析，我们也可以得到一些改进的建议。这些建议差不太多，就不在详细说明。 合理使用这两个工具，优化我们的网页，提高网页加载速度，增强用户体验。 我自己的误解 过去一直以为，一个容器如果没有读到自己的结束标签，那么这个容器就不会在浏览器中显示出来。今天测试了下，却发现浏览器在读到一个容器的开始标签的时候，就可以显示该容器了。关于浏览器如何一个一个的paint HTML中的元素，如果flow它们，这个过程还需要进一步了解。当然，也可以不管过程，只看加载的结果，通过pagespeed和Yslow来优化自己的网页。个人在做布局的时候，还是会秉承一条原则: 尽量让一个父容器小一些！ 参考文献 ...

DOM, BOM BOM 浏览器对象模型 提供了独立于内容而与浏览器窗口进行交互的对象。描述了与浏览器进行交互的方法和接口，可以对浏览器窗口进行访问和操作，譬如可以弹出新的窗口，改变状态栏中的文本，对Cookie的支持，IE还扩展了BOM，加入了ActiveXObject类，可以通过js脚本实例化ActiveX对象等等) 文档结构图 BOM由以一系列相关的对象组成。下图展示了基本的BOM体系结构。 BOM中的对象 Window对象: 是整个BOM的核心，所有对象和集合都以某种方式回接到window对象。Window对象表示整个浏览器窗口，但不必表示其中包含的内容。 Document对象: 实际上是window对象的属性。这个对象的独特之处是唯一一个既属于BOM又属于DOM的对象。从BOM角度看，document对象由一系列集合构成，这些集合可以访问文档的各个部分。 Location对象: 它是window对象和document对象的属性。Location对象表示载入窗口的URL，此外它还可以解析URI. Navigator对象: Navigator包含大量Web浏览器相关的信息。各种浏览器支持该对象的属性和方法不尽相同。 Screen对象: 通过其可以获取用户屏幕相关的信息 DOM 文档对象模型 DOM是针对XML的基于树的API。描述了处理网页内容的方法和接口，是HTML和XML的API，DOM把整个页面规划成由节点层级构成的文档。 DOM本身是与语言无关的API，它并不与Java，JavaScript或其他语言绑定。 特定语言的DOM 针对XHTML和HTML的DOM。这个DOM定义了一个HTMLDocument和HTMLElement做为这种实现的基础。 其他的包括SVG的DOM 对于DOM的支持 各种浏览器对于DOM的支持不一样。 Mozila支持最好，几乎所有的DOM Level 2以及部分DOM Level 3。在 Opera和Safrai支持所有的DOM Level1和大部分DOM Level2。 IE，支持大部分的DOM Level 1。 DOM 的各种 Level DOM Level 1 包括 DOM Core 和 DOM HTML。前者提供了基于XML的文档结构图。后者添加了一些HTML专用的对象和方法，从而扩展了DOM Core. DOM Level 2 引入几个新模块: DOM视图，事件，样式，遍历和范围 DOM Level 3 引入了以统一的方式载入和保存文档的方法。DOM Core被扩展支持所有的XML1.0的特性 http://titan.iteye.com/blog/60389 DOM 事件 onblur="hanshu(this)" 获得焦点: onfocus="hanshu(this)"

XMLHttpRequest, XHR XMLHttpRequest可以提供不重新加载页面的情况下更新网页，在页面加载后在客户端向服务器请求数据，在页面加载后在服务器端接受数据，在后台向客户端发送数据。XMLHttpRequest 对象提供了对 HTTP 协议的完全的访问，包括做出 POST 和 HEAD 请求以及普通的 GET 请求的能力。XMLHttpRequest 可以同步或异步返回 Web 服务器的响应，并且能以文本或者一个 DOM 文档形式返回内容。尽管名为 XMLHttpRequest，它并不限于和 XML 文档一起使用: 它可以接收任何形式的文本文档。XMLHttpRequest 对象是名为 AJAX 的 Web 应用程序架构的一项关键功能。 浏览器支持 XMLHttpRequest 得到了所有现代浏览器较好的支持。唯一的浏览器依赖性涉及 XMLHttpRequest 对象的创建。在 IE 5 和 IE 6 中，必须使用特定于 IE 的 ActiveXObject() 构造函数。正如在 XMLHttpRequest 对象 这一节所介绍的。 W3C 标准化 XMLHttpRequest 对象还没有标准化，但是 W3C 已经开始了标准化的工作，本手册介绍的内容都是基于标准化的工作草案。 当前的 XMLHttpRequest 实现已经相当一致。但是和标准有细微的不同。例如，一个实现可能返回 null，而标准要求是空字符串，或者实现可能把 readyState 设置为 3 而不保证所有的响应头部都可用。 readyState HTTP 请求的状态.当一个 XMLHttpRequest 初次创建时，这个属性的值从 0 开始，直到接收到完整的 HTTP 响应，这个值增加到 4。 状态 名称 描述 Uninitialized 初始化状态。XMLHttpRequest 对象已创建或已被 abort() 方法重置。 1 Open open() 方法已调用，但是 send() 方法未调用。请求还没有被发送。 2 Send Send() 方法已调用，HTTP 请求已发送到 Web 服务器。未接收到响应。 3 Receiving 所有响应头部都已经接收到。响应体开始接收但未完成。 4 Loaded HTTP 响应已经完全接收。 5 个状态中每一个都有一个相关联的非正式的名称，下表列出了状态、名称和含义: ...

img width 标签的 height 和 width 属性设置图像的尺寸。 提示: 为图像指定 height 和 width 属性是一个好习惯。如果设置了这些属性，就可以在页面加载时为图像预留空间。如果没有这些属性，浏览器就无法了解图像的尺寸，也就无法为图像保留合适的空间，因此当图像加载时，页面的布局就会发生变化。 (下面的篇幅详细解释了这个观点) 。 提示: 请不要通过 height 和 width 属性来缩放图像。如果通过 height 和 width 属性来缩小图像，那么用户就必须下载大容量的图像 (即使图像在页面上看上去很小) 。正确的做法是，在网页上使用图像之前，应该通过软件把图像处理为合适的尺寸。

url 转义字符, urlencode url 转义字符, URL escape codes 对与通过get方式提交的url，浏览器在提交前首先根据http协议把参数及其值解析配对。而url的参数间是通过&分割的，这就是浏览器进行参数配置的分割依据。如果你的参数值中含有&等url特殊字符，那么你在服务器端就会拿到意想不到的值。所以必须对url的特殊字符进行转义。 编码的格式为: %加字符的ASCII码，即一个百分号%，后面跟对应字符的ASCII (16进制) 码值。例如 空格的编码值是"%20"。 url转义字符, URL特殊符号及编码 空格 URL中的空格可以用 + 号或者编码 %20 " %22 ' %27 + URL中+号表示空格 %2B , %2C : %3A [ %5B ] %5D / 分隔目录和子目录 %2F 十六进制值 ! %21 ? 分隔实际的 URL 和参数 %3F % 指定特殊字符 %25 # 表示书签 %23 & URL 中指定的参数间的分隔符 %26 ( %28 ) %29 . %2E = %3D , 逗号 %2C { %7B } %7D http://www.wetools.com/url-escape-code http://alipay.iteye.com/blog/68412 ...

cxf wsdl2java wsdl2java -d src -client http://localhost:9000/helloWorld?wsdl 其作用上面的build.xml作用一样。 附加: wsdl2java用法: wsdl2java -p com -d src -all aa.wsdl -p 指定其wsdl的命名空间，也就是要生成代码的包名: -d 指定要产生代码所在目录 -client 生成客户端测试web service的代码 -server 生成服务器启动web service的代码 -impl 生成web service的实现代码 -ant 生成build.xml文件 -all 生成所有开始端点代码: types,service proxy,,service interface, server mainline, client mainline, implementation object, and an Ant build.xml file. 详细用法见: http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html

OAuth2.0 http://baike.baidu.com/view/6619164.htm OAuth 1.0已经在IETF尘埃落定，编号是RFC5894 这也标志这OAuth已经正式成为互联网标准协议。 OAuth 2.0早已经开始讨论和建立的草案。OAuth2.0 很可能是下一代的"用户验证和授权"标准。现在百度开放平台，腾讯开放平台等大部分的开放平台都是使用的OAuth 2.0协议作为支撑。 OAuth (开放授权) 是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源 (如照片，视频，联系人列表) ，而无需将用户名和密码提供给第三方应用。 OAuth 允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站 (例如，视频编辑网站)在特定的时段 (例如，接下来的2小时内) 内访问特定的资源 (例如仅仅是某一相册中的视频) 。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。 OAuth是OpenID的一个补充，但是完全不同的服务。 OAuth 2.0 是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。规范还在IETF OAuth工作组的开发中，按照Eran Hammer-Lahav的说法，OAuth将于2010年末完成。 Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月亦宣布Google API对OAuth 2.0的支援。 认证和授权过程 在认证和授权的过程中涉及的三方包括: 1、服务提供方，用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。 2、用户，存放在服务提供方的受保护的资源的拥有者。 3、客户端，要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站。在认证过程之前，客户端要向服务提供者申请客户端标识。 使用OAuth进行认证和授权的过程如下所示: 用户访问客户端的网站，想操作用户存放在服务提供方的资源。 客户端向服务提供方请求一个临时令牌。 服务提供方验证客户端的身份后，授予一个临时令牌。 客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。 用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。 授权成功后，服务提供方引导用户返回客户端的网页。 客户端根据临时令牌从服务提供方那里获取访问令牌。 服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。 客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。 简单历史回顾 OAuth 1.0在2007年的12月底发布并迅速成为工业标准。 2008年6月，发布了OAuth 1.0 Revision A，这是个稍作修改的修订版本，主要修正一个安全方面的漏洞。 2010年四月，OAuth 1.0的终于在IETF发布了，协议编号RFC 5849。 OAuth 2.0的草案是在今年5月初在IETF发布的。 OAuth is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords. OAuth是个安全相关的协议，作用在于，使用户授权第三方的应用程序访问用户的web资源，并且不需要向第三方应用程序透露自己的密码。 OAuth 2.0是个全新的协议，并且不对之前的版本做向后兼容，然而，OAuth 2.0保留了与之前版本OAuth相同的整体架构。 这个草案是围绕着 OAuth2.0的需求和目标，历经了长达一年的讨论，讨论的参与者来自业界的各个知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。 OAuth 2.0的新特性: 6种全新的流程: User-Agent Flow – 客户端运行于用户代理内 (典型如web浏览器) 。 Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。 Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器 Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。 Client Credentials Flow – 客户端适用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。 Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。 可以通过使用以上的多种流程实现Native应用程序对OAuth的支持 (程序运行于桌面操作系统或移动折本) application support (applications running on a desktop or mobile device) can be implemented using many of the flows above. 持信人token OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过HTTPS发送，从而替换了通过 HMAC 和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。 ...

HttpSessionBindingListener 捕获Session事件的意义: 记录网站的客户登录日志 (登录，退出信息等) 统计在线人数 等等还有很多，呵呵，自己想吧……总之挺重要的。 Session代表客户的会话过程，客户登录时，往Session中传入一个对象，即可跟踪客户的会话。在Servlet中，传入Session的对象如果是一个实现HttpSessionBindingListener接口的对象 (方便起见，此对象称为监听器) ，则在传入的时候 (即调用HttpSession对象的setAttribute方法的时候) 和移去的时候 (即调用HttpSession对象的removeAttribute方法的时候或Session Time out的时候) Session对象会自动调用监听器的valueBound和valueUnbound方法 (这是HttpSessionBindingListener接口中的方法) 。 由此可知，登录日志也就不难实现了。 另外一个问题是，如何统计在线人数，这个问题跟实现登录日志稍微有点不同，统计在线人数 (及其信息) ，就是统计现在有多少个Session实例存在，我们可以增加一个计数器 (如果想存储更多的信息，可以用一个对象来做计数器，随后给出的实例中，简单起见，用一个整数变量作为计数器) ，通过在valueBound方法中给计数器加1，valueUnbound方法中计数器减1，即可实现在线人数的统计。当然，这里面要利用到ServletContext的全局特性。(有关ServletContext的叙述请参考Servlet规范)，新建一个监听器，并将其实例存入ServletContext的属性中，以保证此监听器实例的唯一性，当客户登录时，先判断ServletContext的这个属性是否为空，如果不为空，证明已经创建，直接将此属性取出放入Session中，计数器加1；如果为空则创建一个新的监听器，并存入ServletContext的属性中。 举例说明: 实现一个监听器: // SessionListener.java import java.io.*; import java.util.*; import javax.servlet.http.*; //监听登录的整个过程 public class SessionListener implements HttpSessionBindingListener { public String privateInfo= " “; //生成监听器的初始化参数字符串 private String logString= " “; //日志记录字符串 private int count=0; //登录人数计数器 public SessionListener(String info){ this.privateInfo=info; } public int getCount(){ return count; } public void valueBound(HttpSessionBindingEvent event) ...

cookie, session 具体来说cookie机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制，他需要用户打开客户端的cookie支持。cookie的作用就是为了解决HTTP协议无状态的缺陷所作的努力. 而session机制采用的是一种在客户端与服务器之间保持状态的解决方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。而session提供了方便管理全局变量的方式 session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器。 就安全性来说: 当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。 正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie 从网络服务器观点看所有HTTP请求都独立于先前请求。就是说每一个HTTP响应完全依赖于相应请求中包含的信息 状态管理机制克服了HTTP的一些限制并允许网络客户端及服务器端维护请求间的关系。在这种关系维持的期间叫做会话(session)。 Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie规范。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies 理解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。 ...

Servlet Session http://developer.51cto.com/art/200907/134673.htm 本文向您介绍Servlet Session机制，包括会话管理机制、事件监听等，并结合具体的示例讲解了一个基于Servlet Session登陆系统的实现。 一、 Servlet的会话管理机制 HttpSession接口提供了存储和返回标准会话属性的方法。标准会话属性如会话标识符、应用数据等，都以"键-值"对的形式保存。简而言之，HttpSession接口提供了一种把对象保存到内存、在同一用户的后继请求中提取这些对象的标准办法。在会话中保存数据的方法是setAttribute(String s, Object o)，从会话提取原来所保存对象的方法是getAttribute(String s)。 每当新用户请求一个使用了HttpSession对象的JSP页面，JSP容器除了发回应答页面之外，它还要向浏览器发送一个特殊的数字。这个特殊的数字称为"会话标识符"，它是一个唯一的用户标识符。此后，HttpSession对象就驻留在内存之中，等待同一用户返回时再次调用它的方法。 在客户端，浏览器保存会话标识符，并在每一个后继请求中把这个会话标识符发送给服务器。会话标识符告诉JSP容器当前请求不是用户发出的第一个请求，服务器以前已经为该用户创建了HttpSession对象。此时，JSP容器不再为用户创建新的HttpSession对象，而是寻找具有相同会话标识符的HttpSession对象，然后建立该HttpSession对象和当前请求的关联。 会话标识符以Cookie的形式在服务器和浏览器之间传送。如果客户端不支持cookie，运用url改写机制来保证会话标识符传回服务器。 二、 Servlet Session事件侦听 HttpSessionBindingEvent类 定义 public class HttpSessionBindingEvent extends EventObject 这个事件是在监听到HttpSession发生绑定和取消绑定的情况时连通HttpSessionBindingListener的。这可能是一个session被终止或被认定无效的结果。 事件源是HttpSession.putValue或HttpSession.removeValue。 构造函数 public HttpSessionBindingEvent(HttpSession session, String name); 通过引起这个事件的Session和发生绑定或取消绑定的对象名构造一个新的HttpSessionBindingEvent。 方法 1、getName public String getName(); 返回发生绑定和取消绑定的对象的名字。 2、getSession public HttpSession getSession(); 返回发生绑定和取消绑定的session的名字。 HttpSessionBindingListener接口 定义 public interface HttpSessionBindingListener 这个对象被加入到HTTP的session中，执行这个接口会通告有没有什么对象被绑定到这个HTTP session中或被从这个HTTP session中取消绑定。 方法 1、valueBound public void valueBound(HttpSessionBindingEvent event); 当一个对象被绑定到session中，调用此方法。HttpSession.putValue方法被调用时，Servlet引擎应该调用此方法。 2、valueUnbound public void valueUnbound(HttpSessionBindingEvent event); 当一个对象被从session中取消绑定，调用此方法。HttpSession.removeValue方法被调用时，Servlet引擎应该调用此方法。 Session的事件处理机制与swing事件处理机制不同。Swing采用注册机制，而session没有；当任一session发生绑定或其他事件时，都会触发HttpSessionBindingEvent ，如果servlet容器中存在HttpSessionBindingListener的实现类，则会将事件作为参数传送给session侦听器的实现类。在HttpSessionBindingEvent 中可以通过getsession得到发生绑定和取消绑定的session的名字，而侦听器可以据此做更多处理。 因此，对session的事件侦听，只需实现HttpSessionBindingListener即可。 从servlet2.3增加了 HttpSessionEvent (This is the class representing event notifications for changes to sessions within a web application) HttpSessionActivationListener (Objects that are bound to a session may listen to container events notifying them that sessions will be passivated and that session will be activated.) HttpSessionAttributeListener (This listener interface can be implemented in order to get notifications of changes to the attribute lists of sessions within this web application.) 分别执行不同的任务，处理基本相同。 三、 例子 (zz) 捕获Servlet Session事件的意义: 1、 记录网站的客户登录日志 (登录，退出信息等) 2、 统计在线人数 3、 等等还有很多，呵呵，自己想吧……总之挺重要的。 Session代表客户的会话过程，客户登录时，往Session中传入一个对象，即可跟踪客户的会话。在Servlet中，传入Session的对象如果是一个实现HttpSessionBindingListener接口的对象 (方便起见，此对象称为监听器) ，则在传入的时候 (即调用HttpSession对象的setAttribute方法的时候) 和移去的时候 (即调用HttpSession对象的removeAttribute方法的时候或Session Time out的时候) Session对象会自动调用监听器的valueBound和valueUnbound方法 (这是HttpSessionBindingListener接口中的方法) 。由此可知，登录日志也就不难实现了。 另外一个问题是，如何统计在线人数，这个问题跟实现登录日志稍微有点不同，统计在线人数 (及其信息) ，就是统计现在有多少个Session实例存在，我们可以增加一个计数器 (如果想存储更多的信息，可以用一个对象来做计数器，随后给出的实例中，简单起见，用一个整数变量作为计数器) ，通过在valueBound方法中给计数器加1，valueUnbound方法中计数器减1，即可实现在线人数的统计。当然，这里面要利用到ServletContext的全局特性。(有关ServletContext的叙述请参考Servlet规范)，新建一个监听器，并将其实例存入ServletContext的属性中，以保证此监听器实例的唯一性，当客户登录时，先判断ServletContext的这个属性是否为空，如果不为空，证明已经创建，直接将此属性取出放入Session中，计数器加1；如果为空则创建一个新的监听器，并存入ServletContext的属性中。 举例说明: 实现一个监听器: ...

HttpSessionListener Session创建事件发生在每次一个新的session创建的时候，类似地Session失效事件发生在每次一个Session失效的时候。 这个接口也只包含两个方法，分别对应于Session的创建和失效: public void sessionCreated(HttpSessionEvent se); public void sessionDestroyed(HttpSessionEvent se); 我的web应用上想知道到底有多少用户在使用？ 在网站中经常需要进行在线人数的统计。过去的一般做法是结合登录和退出功能，即当用户输入用户名密码进行登录的时候计数器加1，然后当用户点击退出按钮退出系统的时候计数器减1。这种处理方式存在一些缺点，例如: 用户正常登录后，可能会忘记点击退出按钮，而直接关闭浏览器，导致计数器减1的操作没有及时执行；网站上还经常有一些内容是不需要登录就可以访问的，在这种情况下也无法使用上面的方法进行在线人数统计。 我们可以利用Servlet规范中定义的事件监听器 (Listener) 来解决这个问题，实现更准确的在线人数统计功能。对每一个正在访问的用户，J2EE应用服务器会为其建立一个对应的HttpSession对象。当一个浏览器第一次访问网站的时候，J2EE应用服务器会新建一个HttpSession对象 ，并触发 HttpSession创建事件 ，如果注册了HttpSessionListener事件监听器，则会调用HttpSessionListener事件监听器的sessionCreated方法。相反，当这个浏览器访问结束超时的时候，J2EE应用服务器会销毁相应的HttpSession对象，触发 HttpSession销毁事件，同时调用所注册HttpSessionListener事件监听器的sessionDestroyed方法。 import javax.servlet.http.HttpSessionListener; import javax.servlet.http.HttpSessionEvent; public class SessionCounter implements HttpSessionListener { private static int activeSessions =0; /* Session创建事件 */ public void sessionCreated(HttpSessionEvent se) { ServletContext ctx = event.getSession( ).getServletContext( ); Integer numSessions = (Integer) ctx.getAttribute("numSessions"); if (numSessions == null) { numSessions = new Integer(1); } else { int count = numSessions.intValue( ); numSessions = new Integer(count + 1); } ctx.setAttribute("numSessions", numSessions); } /* Session失效事件 */ public void sessionDestroyed(HttpSessionEvent se) { ServletContext ctx=se.getSession().getServletContext(); Integer numSessions = (Integer)ctx.getAttribute("numSessions"); if(numSessions == null) numSessions = new Integer(0); } else { int count = numSessions.intValue( ); numSessions = new Integer(count - 1); } ctx.setAttribute("numSessions", numSessions); } } 在这个解决方案中，任何一个Session被创建或者销毁时，都会通知SessionCounter 这个类，当然通知的原因是必须在web.xml文件中做相关的配置工作。如下面的配置代码: demo.listener.SessionCounter</listener-class> </listener> 以下两种情况下就会发生sessionDestoryed (会话销毁) 事件: 1.执行session.invalidate()方法时 。 既然LogoutServlet.java中执行session.invalidate()时，会触发sessionDestory()从在线用户 列表中清除当前用户，我们就不必在LogoutServlet.java中对在线列表进行操作了，所以LogoutServlet.java的内容现在是 这样。 ...

ServletContextListener http://www.cnblogs.com/kentyshang/archive/2007/06/26/795878.html ServletContextListener处理Web应用的 servlet上下文(context)的变化的通知。这可以解释为，好像有个人在服务器旁不断地通知我们服务器在发生什么事件。那当然需要监听者了。因 此，在通知上下文(context)初始化和销毁的时候，ServletContextListner非常有用。 import javax.servlet.ServletContextListener; import javax.servlet.ServletContextEvent; import javax.servlet.*; public class MyListener implements ServletContextListener { private ServletContext context = null; /* 这个方法在Web应用服务被移除，没有能力再接受请求的时候被调用。 */ public void contextDestroyed(ServletContextEvent event){ //Output a simple message to the server's console System.out.println("The Simple Web App. Has Been Removed"); this.context = null; } // 这个方法在Web应用服务做好接受请求的时候被调用。 public void contextInitialized(ServletContextEvent event){ this.context = event.getServletContext(); //Output a simple message to the server's console System.out.println("The Simple Web App. Is Ready"); } } ...

web service http://www.cnblogs.com/hanlsheng/archive/2011/01/20/1940367.html 第一章 设计一个简单的web service接口 本章主要内容: 你将学会如何设计一个简单的web service接口 穿越网络提供跨平台操作 假设你想为大众或者业务伙伴提供一种这样的服务: 他们向你发送两个字符串，你把两个字符串进行连接，然后返回给他们。当然在现实世界中，你将提供一些更有用更复杂的服务。 此服务有几个必须满足的需求: 首先，用户可以使用不同的语言( 比如Java，C# 等)以及不同的平台( Windows，Linux等)。你提供的服务对于不同的语言和平台必须是可以访问的。第二，用户可以通过网络对你的服务进行访问。而且必须能够穿越防火墙。 给定了以上需求，最佳的解决方案是提供一个所谓的"web service"。比如，你可以在主机( www.ttdev.com)上提供可访问的web service( 通过/SimpleService 访问，见下图)，所以URL全称是: http: www.ttdev.com/SimpleService. 这被称为web service的"endpoint"( 终端，端点)。web service 可以支持一个或者多个操作。在这个例子中，一个操作被命名为"concat": 然而，你希望为你的每一个web service 操作提供全球唯一标识，这样别人也可以拥有名称为"concat"的操作。如何实现呢？很简单，你可以在名称"concat"前面声明一个"namespace"( 命名空间，比如http: ttdev.com/ss). namespace( 命名空间)的作用同java 中包的作用非常类似，只是表示形式不用而已，包的表示形式为 com.ttdev.foo。全球唯一标识是由namespace和操作名称组成的。Operation(操作)的名称,比如"concat"被称为local name( 本地名称)。全球唯一标识被称为QName( qualified name)。 你可能想知道命名空间(如http: ttdev.com/ss)有什么含义。答案是:没有什么特别的含义。即使这个命名空间是一个URL，但不意味着你能通过浏览器进行访问会获得一个可访问页面。对你来说唯一重要的一点是，这个标识是全球唯一的。因为我已经注册了这个域名ttdev.com，所以它一定是全球唯一的。 值得注意的一点是， namespace (命名空间)与endpoint(终端，端点)是完全不同的概念。endpoint是真实的服务提供地点，而namespace仅仅是一个唯一标识符号。我可以轻易的把服务部署在另外的服务器上，这样web service将会有不同的 endpoint，但是 web service的操作唯一标识( 命名空间+本地名称)可以保持不变。 2.RPC 类型的web service 你的concat 操作将包含两个参数。一个名称为"s1"为string 类型。另一个名称为"s2"同样是string类型。返回值同样是一个string类型: 然而，上图中的string 类型是什么含义呢？是Java的 string类型吗？不是，因为它必须是语言中立的。幸运的是，XML schema spec 定义了一些基本的数据类型，其中包括string类型。每一个数据类型都有一个QName 作为其id。比如: ...

CSS font-style font-style 属性定义字体的风格。 该属性设置使用斜体、倾斜或正常字体。斜体字体通常定义为字体系列中的一个单独的字体。理论上讲，用户代理可以根据正常字体计算一个斜体字体。 normal 默认值。浏览器显示一个标准的字体样式。 italic 浏览器会显示一个斜体的字体样式。 oblique 浏览器会显示一个倾斜的字体样式。 inherit 规定应该从父元素继承字体样式。

servlet listener Listener是一种观察者模式的实现: 我们在web.xml中配置listener的时候就是把一个被观察者放入的观察者的观察对象队列中，当被观察者触发了注册事件时观察者作出相应的反应。在jsp/servlet中具体的实现是在web.xml中注册Listener，由Container在特定事件发生时呼叫特定的实现Listener的类。 总体上说servlet中有主要有3类事件既: Servlet上下文事件、 会话事件与请求事件总共有8个listener接口，我们在web.xml中注册时对应上自己对相应接口的实现类即可: Servlet中的Listener和Event: 在JSP 2.0/Servlet 2.4中，共有八个Listener接口，六个Event类别。 Listener接口 Event类 ServletContextListener ServletContextEvent ServletContextAttributeListener ServletContextAttributeEvent HttpSessionListener HttpSessionEvent HttpSessionActivationListener HttpSessionAttributeListener HttpSessionBindingEvent HttpSessionBindingListener ServletRequestListener ServletRequestEvent ServletRequestAttributeListener ServletRequestAttributeEvent 分别介绍: １.ServletContextListener [接口方法] contextInitialized(), contextDestroyed() [接收事件] ServletContextEvent [触发场景] 在Container加载Web应用程序时 (例如启动 Container之后) ，会呼叫contextInitialized()，而当容器移除Web应用程序时，会呼叫contextDestroyed()方法。 2. ServletContextAttributeListener [接口方法] attributeAdded()、 attributeReplaced()、attributeRemoved() [接收事件] ServletContextAttributeEvent [触发场景] 若有对象加入为application (ServletContext) 对象的属性，则会呼叫attributeAdded()，同理在置换属性与移除属性时，会分别呼叫attributeReplaced()、attributeRemoved()。 3. HttpSessionListener [接口方法] sessionCreated(), sessionDestroyed () [接收事件] HttpSessionEvent [触发场景] 在session (HttpSession) 对象被创建或被消毁时，会分别调用这两个方法。 4. HttpSessionAttributeListener [接口方法] attributeAdded()、 attributeReplaced()、attributeRemoved() [接收事件] HttpSessionBindingEvent ...

Servlet Filter @Servlet里的过滤器的主要作用 1，判断用户是否登录。 2，网络聊天系统或论坛，功能是过滤非法文字 3，统一解决编码 @Servlet3.0之前怎么创建一个过滤器 1，生成一个普通的class类，实现Filter接口(javax.servlet.Filter)。 2，重写接口里面的三个方法: init，doFilter，destroy。 其中的doFilter方法的第一个参数为ServletRequest对象。此对象给过滤器提供了对进入的信息 (包括表单数据、cookie和HTTP请求头) 的完全访问。第二个参数为ServletResponse，通常在简单的过滤器中忽略此参数。最后一个参数为FilterChain，此参数用来调用servlet或JSP页。 3，然后在web.xml配置过滤器。 具体例子:1.首先写一个权限过滤filter类,实现Filter接口 <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ```java import javax.servlet.Filter; import javax.servlet.FilterConfig; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.FilterChain; import java.io.IOException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpSession; import javax.servlet.http.HttpServletResponse; public class RightFilter implements Filter { public void init(FilterConfig filterConfig) throws ServletException { } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; //如果处理HTTP请求，并且需要访问诸如getHeader或getCookies等在ServletRequest中无法得到的方法 //就要把此request对象构造成HttpServletRequest HttpServletResponse res = (HttpServletResponse) response; HttpSession session = req.getSession(true); //从session里取的用户名信息 String username = (String) session.getAttribute("username"); //判断如果没有取到用户信息,就跳转到登陆页面 if (username == null || "".equals(username)) { //跳转到登陆页面 res.sendRedirect("http://"+req.getHeader("Host")+"/login.jsp"); } else { //已经登陆,继续此次请求 chain.doFilter(request,response); //调用FilterChain对象的doFilter方法 //Filter接口的doFilter方法取一个FilterChain对象作为它的一个参数 //在调用此对象的doFilter方法时，激活下一个相关的过滤器 //如果没有另一个过滤器与servlet或JSP页面关联，则servlet或JSP页面被激活 } } public void destroy() { } } ## 2.然后在web.xml里配置需要登陆权限验证的JSP文件: ## a.如果是某个具体的JSP文件(如a.jsp)需要登陆验证 ## <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < web-app > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ... <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-name > right filter-name > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-class > com.taihuatalk.taihua.common.RightFilter filter-class > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> filter > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-mapping > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-name > right filter-name > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < url-pattern > /a.jsp url-pattern > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> filter-mapping > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ... <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> web-app > ## b.如果是某一个目录(如a/目录)整个目录下的文件都需要登陆验证: ## <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < web-app > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ... <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-name > right filter-name > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-class > com.taihuatalk.taihua.common.RightFilter filter-class > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> filter > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-mapping > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < filter-name > right filter-name > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> < url-pattern > /a/* url-pattern > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> filter-mapping > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ... <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> web-app > <img alt="" src="http://images.csdn.net/syntaxhighlighting/OutliningIndicators/None.gif" align="top" /> ## ## _@Servlet3.0中的创建过滤器: 使用@WebFilter_ ## @WebFilter用于将一个类声明为过滤器，该注解将会在部署时被容器处理，容器将根据具体的属性配置将相应的类部署为过滤器。该注解具有下表给出的一些常用属性(以下所有属性均为可选属性，但是value、urlPatterns、servletNames三者必需至少包含一个，且value和urlPatterns不能共存，如果同时指定，通常忽略value的取值): ## 属性名类型描述 ## 1.filterNameString指定过滤器的name属性。 ## 2.valueString[]该属性等价于urlPatterns属性。但是两者不应该同时使用。 ## 3.urlPatternsString[]指定一组过滤器的URL匹配模式。等价于标签。 ## 4.servletNamesString[]指定过滤器将应用于哪些Servlet。取值是@WebServlet中的name属性的取值，或者是web.xml中的取值。 ## 5.dispatcherTypesDispatcherType指定过滤器的转发模式。具体取值包括: ## ◆ASYNC、ERROR、FORWARD、INCLUDE、REQUEST。 ## ◆initParamsWebInitParam[]指定一组过滤器初始化参数，等价于标签。 ## ◆asyncSupportedboolean声明过滤器是否支持异步操作模式，等价于标签。 ## ◆descriptionString该过滤器的描述信息，等价于标签。 ## ◆displayNameString该过滤器的显示名，通常配合工具使用，等价于标签。 ## 一个简单的示例: ## @WebFilter(filterName = "AuthenticateFilter", urlPatterns ={"/stock.jsp", "/getquote"}) public class AuthenticateFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String username = ((HttpServletRequest) request).getParameter("uname"); String password = ((HttpServletRequest) request).getParameter("password"); if (username == null || password == null) { ((HttpServletResponse) response).sendRedirect("index.jsp"); ## } if (username.equals("admin") && password.equals("admin")) { chain.doFilter(request, response); ## } else { ((HttpServletResponse) response).sendRedirect("index.jsp"); ## } } public void destroy() { } ## public void init(FilterConfig filterConfig) { } } ## 如此配置之后，就可以不必在web.xml中配置相应的和元素了，容器会在部署时根据指定的属性将该类发布为过滤器。 ## ## _具体Servlet3.0相关的内容请参考: http://blog.csdn.net/flfna/archive/2010/05/16/5598201.aspx_ ## Filter 技术是Servlet 2.3 新增加的功能. Filter的使用户可以改变一 个request或修改一个response。 Filter 不是一个servlet,它不能产生一个response,但是他能够在一个request到达servlet之前预先处理request,也可以在一个响应离开 servlet时处理response。 一个filter 包括: 以常规的方式调用资源 (即，调用servlet或JSP页面) 。 利用修改过的请求信息调用资源。 ③调用资源，但在发送响应到客户机前对其进行修改。 ④阻止该资源调用，代之以转到其他的资源，返回一个特定的状态代码或生成替换输出。 2. 在servlet被调用之前检查servlet request; 3. 根据需要修改request头和request数据; 4. 根据需要修改response头和response数据; 5. 在servlet被调用之后截获. Filter和servlet的对应关系为多对多的关系 ，也就是说你可以配置一个filter 到一个或多个servlet;而一个servlet可以有多个filter。几个实用的filter 包括: 用户辨认filter,日志filter,审核filter,加密filter,符号filter,能改变xml内容的XSLT filter等. 一个filter必须实现javax.servlet.Filter接口并定义三个方法: 1.void setFilterConfig(FilterConfig config) //设置filter 的配置对象; 2. FilterConfig getFilterConfig() //返回filter的配置对象; 3. void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) //执行filter 的工作. 服务器每次只调用setFilterConfig方法一次准备filter 的处理;调用doFilter方法多次以处理不同的请求.FilterConfig接口有方法可以找到filter名字及初始化参数信息.服务器可以设置 FilterConfig为空来指明filter已经终结. 每一个filter从doFilter()方法中得到当前的request及response.在这个方法里,可以进行任何的针对request及 response的操作.(包括收集数据,包装数据等).filter调用chain.doFilter()方法把控制权交给下一个filter.一个 filter在doFilter()方法中结束.如果一个filter想停止request处理而获得对response的完全的控制,那它可以不调用下 一个filter. 一个filter可以包装request 或response以改变几个方法和提供用户定制的属性.Api2.3提供了HttpServletRequestWrapper 和HttpServletResponseWrapper来实现.它们能分派最初的request和response.如果要改变一个方法的特性,必须继 承wapper和重写方法.下面是一段简单的日志filter用来记录所有request的持续时间. 当server调用setFilterConfig(),filter保存config信息.在doFilter()方法中通过config信息得到 servletContext.如果要运行这个filter,必须去配置到web.xml中.以tomcat4.01为例: <filter> <filter-name> log //filter 名字 ```xml 1.2 Servlet过滤器的基本原理 ...

Servlet.Filter filter功能.它使用户可以改变一个 request和修改一个response. Filter 不是一个servlet,它不能产生一个response,它能够在一个request到达servlet之前预处理request,也可以在离开 servlet时处理response.换种说法,filter其实是一个"servlet chaining"(servlet 链).一个filter 包括: 在servlet被调用之前截获; 在servlet被调用之前检查servlet request; 根据需要修改request头和request数据; 根据需要修改response头和response数据; 在servlet被调用之后截获. 你能够配置一个filter 到一个或多个servlet;单个servlet或servlet组能够被多个filter 使用.几个实用的filter 包括:用户辨认filter,日志filter,审核filter,加密filter,符号filter,能改变xml内容的XSLT filter等. 一个filter必须实现javax.servlet.Filter接口并定义三个方法: 1.void setFilterConfig(FilterConfig config) //设置filter 的配置对象; FilterConfig getFilterConfig() //返回filter的配置对象; void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) //执行filter 的工作. 服务器每次只调用setFilterConfig方法一次准备filter 的处理;调用doFilter方法多次以处理不同的请求.FilterConfig接口有方法可以找到filter名字及初始化参数信息.服务器可以设置 FilterConfig为空来指明filter已经终结. 每一个filter从doFilter()方法中得到当前的request及response.在这个方法里,可以进行任何的针对request及 response的操作.(包括收集数据,包装数据等).filter调用chain.doFilter()方法把控制权交给下一个filter.一个 filter在doFilter()方法中结束.如果一个filter想停止request处理而获得对response的完全的控制,那它可以不调用下 一个filter. 一个filter可以包装request 或response以改变几个方法和提供用户定制的属性.Api2.3提供了HttpServletRequestWrapper 和HttpServletResponseWrapper来实现.它们能分派最初的request和response.如果要改变一个方法的特性,必须继 承wapper和重写方法.下面是一段简单的日志filter用来记录所有request的持续时间. public class LogFilter implements Filter { FilterConfig config; public FilterConfig getFilterConfig() { return config; } @Override public void init(FilterConfig filterConfig) throws ServletException { this.config = filterConfig; } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { ServletContext context = getFilterConfig().getServletContext(); long bef = System.currentTimeMillis(); try { System.out.println("before do filter"); chain.doFilter(request, response); // no chain parameter needed here } catch (IOException e) { e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. } catch (ServletException e) { e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. } long aft = System.currentTimeMillis(); context.log("Request to " + request.getRemoteAddr() + ": " + (aft - bef)); System.out.println("log filter..."+ (aft - bef)); } @Override public void destroy() { //To change body of implemented methods use File | Settings | File Templates. } } 当server调用setFilterConfig(),filter保存config信息.在doFilter()方法中通过config信息得到servletContext.如果要运行这个filter,必须去配置到web.xml中.以tomcat4.01为例: ...