Web

‘URL中#号(井号)的作用’ a href="#" 这表示一个空链接 这是一个空连接 href="#" #可以改成你要连接的地址 点击就链接到你的网址 这里可以随便你放什么字 这是html超链接格式,href是说超链接的目标,#就是自身 1. 井号在URL中指定的是页面中的一个位置 井号作为页面定位符出现在URL中,比如: http://www.httpwatch.com/features.htm#print ,此URL表示在页面features.htm中print的位置。浏览器读取这个URL后,会自动将print位置滚动至可视区域。 2.井号后面的数据不会发送到HTTP请求中 当时使用类似HttpWatch工具时,你是无法在Http请求中找到井号后面的参数的,原因是井号后面的参数是针对浏览器起作用的而不是服务器端。 3. 任务位于井号后面的字符都是位置标识符 不管第一个井号后面跟的是什么参数,只要是在井号后面的参数一律看成是位置标识符。 比如这样一个链接 (http://example.com/?color=#ffff&shape=circle) ,后面跟的参数是颜色和形状,但是服务器却并不能理解URL中的含义。服务器接收到的只是: http://example.com/?color= 4. 改变井号后面的参数不会触发页面的重新加载但是会留下一个历史记录 仅改变井号后面的内容,只会使浏览器滚动到相应的位置,并不会重现加载页面。 比如从_http://www.httpwatch.com/features.htm#filter_到_http://www.httpwatch.com/features.htm#print_,浏览器并不会去重新请求页面,但是此操作会在浏览器的历史记录中添加一次记录,即你可以通过返回按钮回答上次的位置。这个特性对Ajax来说特别的有用,可以通过设置不同井号值,来表示不同的访问状态,并返回不同的内容给用户。 (注: 在IE6和IE7下井号的改变不会增加历史记录。) 5、可以通过javascript使用window.location.hash来改变井号后面的值 window.location.hash这个属性可以对URL中的井号参数进行修改,基于这个原理,我们可以在不重载页面的前提下创造一天新的访问记录。如标记框架页面当前的页面: 除此之外,HTML 5新增的onhashchange事件,当#值发生变化时,就会触发这个事件。 6. Googlebot对井号的过滤机制 默认情况下Google在索引页面的时候会忽略井号后面的参数,同时也不会去执行页面中的javascript。然而谷歌为了支持对Ajax生成内容的索引,定义了如果在URL中使用"#!",则Google会自动将其后面的内容转成查询字符串_escaped_fragment_的值。 比如最新的twitter URL: http://twitter.com/#!/username,Google会自动请求_http://twitter.com/?escaped_fragment=/username_来获取Ajax内容。 另外可以用#结合?等元素来标记流量来源,比如区分竞价和自然流量等,这个就很给力了. http://blog.163.com/seo_luofeng/blog/static/17657502420120913641444/

sk_buff sk_buff (internal networking structure used by linux kernel) sk_buff的意思是socket buffer，这是Linux网络子系统中的核心数据结构 https://liu-jianhao.github.io/2019/05/linux%E5%86%85%E6%A0%B8%E7%BD%91%E7%BB%9C%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%901sk_buff%E7%BB%93%E6%9E%84/ tcp连接的资源占用 size of sk_buff (internal networking structure used by linux kernel) the read and write buffer for a connection the size of buffers can be tweaked as required root@x:~# sysctl -A | grep net | grep mem check for these variables these specify the maximum default memory buffer usage for all network connections in kernel net.core.wmem_max = 131071 ...

getRequestDispatcher()， sendRedirect() 1.getRequestDispatcher(url)是请求转发，前后页面共享一个request。 RequestDispatcher 对象从客户端获取请求request，并把它们传递给服务器上的servlet,html或jsp。 它有两个方法: forward()和include()具体如下 void forward(ServletRequest request,ServletResponse response) 用来传递request的，可以一个Servlet接收request请求，另一个Servlet用这个request请求来产生response。request传递的请求，response是客户端返回的信息。forward要在response到达客户端之前调用，也就是 before response body output has been flushed。如果不是的话，它会报出异常。 void include(ServletRequest request,ServletResponse response) 用来记录保留request和 response，以后不能再修改response里表示状态的信息。 request.getRequestDispatcher(url).forward(request,response)是直接将请求转发到指定URL，所以该请求能够直接获得上一个请求的数据，request对象始终存在，不会重新创建。 forward 发生在服务器内部, 在浏览器完全不知情的情况下发给了浏览器另外一个页面的response. 这时页面收到的request不是从浏览器直接发来了,可能己经放了数据。 请求转发时如果要传递参数可以这样用: request.setAttribute(“name”,“Michael”); request.getAttribute(“name”); 2.sendRedirect(url)重定向到指定URL，会新建request对象。 这是因为 redirect 会首先发一个response给浏览器, 然后浏览器收到这个response后再发一个requeset给服务器, 然后服务器发新的response给浏览器,这时页面收到的request是从浏览器新发来的,所以上一个request的数据会丢失。 如果要传递参数只有在url后加参数的方式，比如url?type=test才能实现。 3.ServletContext.sendRedirect(String url)中的url只能使用绝对路径; 而ServletRequest.getRequestDispatcher(String url)中的url可以使用相对路径。h这是因为ServletRequest具有相对路径的概念;而ServletContext对象无此概念。 PS:如果需要把请求转移到另外一个WebApp中的某个地址，可以按下面的步骤做法: 获得另外一个WebApp的ServletConext对象(currentServletContext.getContext(uripath)). 调用ServletContext.getRequestDispatcher(String url)方法。

CDN CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度 CDN 内容分发网络 (Content Delivery Network,简称CDN) 将源站内容分发至全国所有的节点,缩短用户查看对象的延迟,提高用户访问网站的响应速度与网站的可用性,解决网络带宽小、用户访问量大、网点分布不均等问题

tomcat启动jvm内存设置 配置tomcat调用的虚拟机内存大小 (1) 直接设置tomcat Linux 修改TOMCAT_HOME/bin/catalina.sh 位置cygwin=false前。 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" (仅做参考，具体数值根据自己的电脑内存配置) windows 修改TOMCAT_HOME/bin/catalina.bat 第一行加上 JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" (2) 配置环境变量 环境变量中设 变量名: JAVA_OPTS 变量值: -Xms512m -Xmx512m https://www.cnblogs.com/oskyhg/p/6549877.html

细化解析 不同类型数据库的死锁问题 论坛中有很多关于死锁问题的讨论，在理论方面，R.Ramakrishnan的《Database management systems》也有非常精辟的阐述。就实际开发而言，不同的数据库环境有着不同的处理方法，不同的体系架构也会导致不同的结果,下面来简单介绍一下不同类型数据库的死锁问题。 1.MSSQL、DB2、Oracle之类的现代DBMS或者中间件可以帮助我们自动解决绝大部分死锁，其余一部分难以处理的死锁则由DBA在数据库控制端手工处理。就应用程序而言，不需要在源代码级过多考虑地考虑死锁问题。 2.死锁的发生对系统的性能和吞吐量有着明显的影响，但只要存在针对共享数据资源的大规模并发访问的情况，那么死锁是不可避免的。 理论上，预防死锁的最好的途径是: 给每一个transaction设定一个优先级，同时确保较低优先级的事务不必等待较高优先级事务释放共享资源，反过来，也确保较高优先级的事务能够立刻取得相应的资源。如果开发人员无法判别事务的优先级，那么可以考虑在每个事务开始时赋予它一个的时间戳，依据时间戳的先后来判定事务的优先级，这类似于FIFO队列。在这方面，现代DBMS都提供了相应的语言支持。但是，假设由于网络故障而导致高优先级的事务无法commit或者rollback，那么是否其他低级别事务便要一直等待或者被抛弃？或者一个事务中的update操作施加了多个表级锁，并且占用了大量时间，那么即便这种事务从逻辑上并不合理，是否也要保持它的高优先级？ 针对稀缺资源的竞争在任何场合都是正常的，死锁出现的因果关系给予我一个提示，就是不能盲目地依赖DBMS和DBA在死锁发生后再去解决死锁问题，那样必然已经对用户体验造成了消极影响。开发人员在设计过程中，需要更多地研判可能的并发访问问题。这些问题可能包括: 尽可能缩短事务。在同一DB中并发执行多个需要长时间运行的事务时，发生死锁的概率较大。事务运行时间越长，其持有exclusive锁或update锁的时间便越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。同时，涉及多个表的查询更新操作，若比较耗时，尽量不要放在一个事务内处理，能分割便分割。若不能分割，便尽可能使之在业务量较小的时间(例如子夜或者午餐时间)执行。 尽可能按同一顺序访问数据对象。如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。 避免编写包含用户交互的事务。因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，若用户不能及时反馈，则此事务将挂起。因而将严重降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。 使用低隔离级别。确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取 (未修改) 的数据，而不必等待第一个事务完成。使用较低的隔离级别 (例如提交读) 而不使用较高的隔离级别 (例如可串行读) 可以缩短持有共享锁的时间，从而降低了锁定争夺。 考虑体系结构的优化与代码重构，提高系统整体的运行效率。例如尽可能不要采用类似EJB的效率低下的计算模型，或者将复杂的业务置于编译存储过程中执行。 通过程序控制事务提交的时机。如果一次检索出了10万条记录但只更改了其中的100条，就可以通过代码来执行100个update。或是用分段提交，即所有的修改使用多个事务进行提交，但这样会使事务不完整，应酌情使用。 将经常更新的数据库和查询数据库分开。定期将不改变的数据导入查询数据库中，这样查询和更新就可以分开进行，而降低死锁机率。 在进行数据库模式设计时，注意外键引用的完整性，并对外键加索引。如果更新了父表的主键，由于外键上没有索引，所以子表会被锁定；如果删除了父表中的一行，整个子表也会被锁定。

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

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 个状态中每一个都有一个相关联的非正式的名称，下表列出了状态、名称和含义: ...

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的内容现在是 这样。 ...

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 ...