1. @WebServlet(name = "GetQuoteServlet",  urlPatterns = {"/getquote"} )

2. public class GetQuoteServlet extends HttpServlet {

3.     @Override

4.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

5.             throws ServletException, IOException {

6.         PrintWriter out = response.getWriter();

7.         try {

8.             String symbol = request.getParameter("symbol");

9.             out.println("<h1>Stock Price is</h1>" + StockQuoteBean.getPrice(symbol);

10.         } finally {

11.             out.close();

12.         }

13.     }

14. }

15.

16. public class StockQuoteBean {

17. private StockQuoteServiceEntity serviceEntity = new StockQuoteServiceEntity();

18.     public double getPrice(String symbol) {

19.         if(symbol !=null )  {

20. return serviceEntity.getPrice(symbol);

21.          } else {

22.             return 0.0;

23.         }

24.     }

25. }

复制代码

在上面的例子中，一个Servlet只对应了一个urlPattern。实际上一个Servlet可以对应多个urlPattern，我们可以这样定义：

1. @WebServlet(name = "GetQuoteServlet",  urlPatterns = {"/getquote",  "/stockquote"} )

2. public class GetQuoteServlet extends HttpServlet {

3.     @Override

4.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

5.             throws ServletException, IOException {

6.         PrintWriter out = response.getWriter();

7.         try {

8.             String symbol = request.getParameter("symbol");

9.             out.println("<h1>Stock Price is</h1>" + StockQuoteBean.getPrice(symbol);

10.         } finally {

11.             out.close();

12.         }

13.     }

14. }

复制代码

@WebFilter
我们可以使用@WebFilter注解来定义filter。这个注解可以被应用在实现了javax.servlet.Filter接口的类上。同样的，urlPattern属性是必须指定的。下面就是一个例子。

1. @WebFilter(filterName = "AuthenticateFilter", urlPatterns = {"/stock.jsp", "/getquote"})

2. public class AuthenticateFilter implements Filter {

3.

4.     public void doFilter(ServletRequest request, ServletResponse response,

5.             FilterChain chain)     throws IOException, ServletException {

6.         String username = ((HttpServletRequest) request).getParameter("uname");

7.         String password = ((HttpServletRequest) request).getParameter("password");

8.           if (username == null || password == null) {

9.                  ((HttpServletResponse) response).sendRedirect("index.jsp");            }

10. if (username.equals("admin") && password.equals("admin")) {

11.                 chain.doFilter(request, response);      }

12. else {

13.                 ((HttpServletResponse) response).sendRedirect("index.jsp");         }

14.          }

15.

16.     public void destroy() {

17.     }

18.     public void init(FilterConfig filterConfig) {

19.     }

20. }

复制代码

@WebInitParam
可以使用@WebInitParam注解来制定Servlet或filter的初始参数。当然我们也可以使用@WebServlet或@WebFileter的initParam属性来指定初始参数。下面是使用@WebInitParam的例子：

1. @WebServlet(name = "GetQuoteServlet", urlPatterns = {"/getquote"})

2. @WebInitParam(name = "default_market", value = "NASDAQ")

3. public class GetQuoteServlet extends HttpServlet {

4.     @Override

5.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

6.             throws ServletException, IOException {

7.         response.setContentType("text/html;charset=UTF-8");

8.         PrintWriter out = response.getWriter();

9.         try {

10.             String market = getInitParameter("default_market");

11.             String symbol = request.getParameter("symbol");

12.             out.println("<h1>Stock Price in " + market + " is</h1>" + StockQuoteBean.getPrice(symbol, market));

13.         } finally {

14.             out.close();

15.         }

16.     }

17. }

复制代码

下面是使用initParam属性的例子：

1. @WebServlet(name = "GetQuoteServlet",

2.             urlPatterns = {"/getquote"},

3.             initParams={@WebInitParam(name="default_market",  value="NASDAQ")}

4.            )

5. public class GetQuoteServlet extends HttpServlet {

6.     @Override

7.     protected void doGet(HttpServletRequest request, HttpServletResponse response)

8.             throws ServletException, IOException {

9.         response.setContentType("text/html;charset=UTF-8");

10.         PrintWriter out = response.getWriter();

11.         try {

12.             String market = getInitParameter("default_market");

13.             String symbol = request.getParameter("symbol");

14.             out.println("<h1>Stock Price in " + market + " is</h1>" + StockQuoteBean.getPrice(symbol, market));

15.         } finally {

16.             out.close();

17.         }

18.     }

19. }

复制代码

@WebListener
@WebListener注解被应用在作为listener监听web应用程序事件的类上，所以@WebListener能够被应用在实现了ServletContextListener，ServletContextAttributeListener，ServletRequestListener，ServletRequestAttributeListener，HttpSessionListener和HttpSessionAttributeListener接口的类上。在下面的例子中，该类实现了ServletContextListener接口。

1. @WebListener

2. public class QuoteServletContextListener implements ServletContextListener {

3.    public void contextInitialized(ServletContextEvent sce) {

4.    ServletContext context = sce.getServletContext();

5. context.setInitParameter(“default_market”, “NASDAQ”);

6. }

7. public void contextDestroyed(ServletContextEvent sce) {

8. }

9. }

复制代码

@MultipartConfig
使用@MultipartConfig注解来指定Servlet要求的multipart MIME类型。这种类型的MIME附件将从request对象中读取。
The Metadata and Common Annotations元数据与通用的注解
除了以上的Servlet特定的注解之外，Servlet3.0还支持JSR175（Java元数据规范）和JSR250（Java平台通用注解）所规定的注解，包括：
    * 安全相关的注解，如 @DeclareRoles 和 @RolesAllowed
    * 使用EJB的注解，如 @EJB 和 @EJBs
    * 资源注入相关的注解，如 @Resource 和 @Resources
    * 使用JPA的注解，如 @PersistenceContext, @PersistenceContexts, @PersistenceUnit, 和 @PersistenceUnits
    * 生命周期的注解，如 @PostConstruct和 @PreDestroy
    * 提供WebService引用的注解，如 @WebServiceRef and @WebServiceRefs
注解和web.xml哪个会生效
注解的引入使得web.xml变成可选的了。但是，我们还是可以使用web.xml。容器会根据web.xml中的metadata-complete元素的值来决定使用web.xml还是使用注解。如果该元素的值是true，那么容器不处理注解，web.xml是所有信息的来源。如果该元素不存在或者其值不为true，容器才会处理注解。
Web框架的可插入性
我们前面说过了Servlet3.0的改进之一就是使得我们能够将框架和库插入到web应用程序中。这种可插入性减少了配置，并且提高了web应用程序的模块化。Servlet3.0是通过web模块布署描述片段（简称web片段）来实现插入性的。
一个web片段就是web.xml文件的一部分，被包含在框架特定的Jar包的META-INF目录中。Web片段使得该框架组件逻辑上就是web应用程序的一部分，不需要编辑web布署描述文件。
Web片段中使用的元素和布署文件中使用的元素基本相同，除了根元素不一样。Web片段的根元素是<web-fragment>,而且文件名必须叫做web-fragment.xml。容器只会在放在WEB-INF\lib目录下的Jar包中查找web-fragment.xml文件。如果这些Jar包含有web-fragment.xml文件，容器就会装载需要的类来处理他们。
在web.xml中，我们要求Servlet的name必须唯一。同样的，在web.xml和所有的web片段中，Servlet的name也必须唯一。
下面就是一个web-fragment的例子：
web-fragment.xml

1. <web-fragment>

2. <servlet>

3. <servlet-name>ControllerServlet</servlet-name>

4. <servlet-class>com.app.control.ControllerServlet</servlet-class>

5. </servlet>

6. <listener>

7. <listener-class>com.listener.AppServletContextListener</listener-class>

8. </listener>

9. </web-fragment>

复制代码

框架的Jar包是放在WEB-INF\lib目录下的，但是Servlet3.0提供两种方法指定多个web片段之间的顺序：
   1. 绝对顺序
   2. 相对顺序
我们通过web.xml文件中的<absolute-ordering>元素来指定绝对顺序。这个元素有之元素name，name的值是各个web片段的name元素的值。这样就指定了web片段的顺序。如果多个web片段有相同的名字，容器会忽略后出现的web片段。下面是一个指定绝对顺序的例子：
web.xml

1. <web-app>

2. <name>DemoApp</name>

3. <absolute-ordering>

4. <name>WebFragment1</name>

5. <name>WebFragment2</name>

6. </absolute-ordering>

7. ...

8. </web-app>

复制代码

相对顺序通过web-fragment.xml中的<ordering>元素来确定。Web片段的顺序由<ordering>的子元素<before>,<after>和<others>来决定。当前的web片段会放在所有的<before>元素中的片段之前。同样的，会放在所有的<after>元素中的片段之后。<others>用来代替所有的其他片段。注意只有当web.xml中没有<absolute-ordering>时，容器才会使用web片段中定义的相对顺序。
下面是一个帮助理解相对顺序的例子：
web-fragment.xml

1. <web-fragment>

2. <name>WebFragment1</name>

3. <ordering><after>WebFragment2</after></ordering>

4. ...

5. </web-fragment>

复制代码

web-fragment.xml

1. <web-fragment>

2. <name>WebFragment2</name>

3. ..

4. </web-fragment>

复制代码

web-fragment.xml

1. <web-fragment>

2. <name>WebFragment3</name>

3. <ordering><before><others/></before></ordering>

复制代码

..
</web-fragment>
这些文件将会按照下面的顺序被处理：
   1. WebFragment3
   2. WebFragment2
   3. WebFragment1
包含WebFragment3的Jar文件被最先处理，包含WebFragment2的文件被第二个处理，包含WebFragment1的文件被最后处理。
如果既没有定义绝对顺序，也没有定义相对顺序，那么容器就认为所有的web片段间没有顺序上的依赖关系。
Servlet中的异步处理
很多时候Servlet要和其他的资源进行互动，例如访问数据库，调用web service。在和这些资源互动的时候，Servlet不得不等待数据返回，然后才能够继续执行。这使得Servlet调用这些资源的时候阻塞。Servlet3.0通过引入异步处理解决了这个问题。异步处理允许线程调用资源的时候不被阻塞，而是直接返回。AsyncContext负责管理从资源来的回应。AsyncContext决定该回应是应该被原来的线程处理还是应该分发给容器中其他的资源。AsyncContext有一些方法如start，dispatch和complete来执行异步处理。
要想使用Servlet3.0的异步处理，我们需要设置@Webservlet和@WebFilter注解的asyncSupport属性。这个属性是布尔值，缺省值是false。
Servlet3.0的异步处理可以很好的和AJAX配合。在Servlet的init方法中，我们能够访问数据库或从JMS读取消息。在doGet或doPost方法中，我们能够启动异步处理，AsyncContext会通过AsyncEvent和AsyncListener来管理线程和数据库操作/JMS操作自己的关系。
已有API的改进
除了这些新特性之外，Servlet3.0还对以往已经存在的API做了一些改进。
HttpServletRequest
To support the multipart/form-data MIME type, the following methods have been added to the HttpServletRequest interface:
为了支持multipart/form-data MIME类型，在HttpServletRequest接口中添加了项目的方法：
    * Iterable<Part> getParts()
    * Part getPart(String name)
Cookies
为了避免一些跨站点攻击，Servlet3.0支持HttpOnly的cookie。HttpOnly cookie不想客户端暴露script代码。Servlet3.0在Cookie类中添加了如下的方法来支持HttpOnly cookie：
    * void setHttpOnly(boolean isHttpOnly)
    * boolean isHttpOnly()
ServletContext
通过在ServletContext中添加下面的方法，Servlet3.0允许Servlet或filter被编程的加入到context中：
    * addServlet(String servletName, String className)
    * addServlet(String servletName, Servlet servlet)
    * addServlet(String servletName, Class<? extends Servlet> servletClass)
    * addFilter(String filterName, String className)
    * addFilter(String filterName, Filter filter)
    * addFilter(String filterName, Class<? extends Filter>filterClass)
    * setInitParameter (String name, String Value)

Servlet3.0新功能: 异步处理

   @WebServlet("/test" asyncSupported=true)   public class MyServlet extends HttpServlet {       ScheduledThreadPoolExecutor executor = null;        public void init(ServletConfig arg0) throws ServletException {                   executor = new ThreadPoolExecutor(10);//独立的线程池处理请求        }        public void doGet(HttpServletRequest req, HttpServletResponse res) {            ...            AsyncContext aCtx = request.startAsync(req, res);            executor.execute(new AsyncWebService(aCtx));//异步处理        }   }   public class AsyncWebService implements Runnable {        AsyncContext ctx;        public AsyncWebService(AsyncContext ctx) {            this.ctx = ctx;        }        public void run() {//处理请求            //Do something here ...            // Dispatch the request to render the result to a JSP.            ctx.dispatch("/render.jsp");   }}

Jquery获得select下拉选项option的值:

<script type"text/javascript">

$(document).ready(function() {

$("#selProv").change(function(){

alert( $("#selProv option:selected").text() );})

});
//alert($("#selProv option[value='01']").val());//也可以这样获得一个值
</script>

<select id="selProv">

<option value="1">text111111</option>

<option value="2">text222222</option>

</select>

用javascript的写的：

        var str = document.getElementById("stBegin");
        alert(str.options[str.selectedIndex].value);

如何添加select的option呢？

有如下两种方法，当然还有其它的方法，下面的只是经常用到：

①JS代码：

var op = new Option("text", "value");//创建一个option对象
op.selected = true;//设置其为默认选中项
$("#stBegin")[0].options.add(op);//添加到select对像

 ②JQuery代码：

最近在蓝色理想转悠，发现很多朋友提出有关DIV+CSS排版问题，以及IE与FF的兼容问题。怎么问的都有，结果就是一个——显示很奇怪，很难调整。我们浏览的大多数网站，或者用Dreamweaver创建一个新的网页文档时，源码的顶部都会有DocType声明，但是很多人没有注意它，甚至在创作时候直接将它删掉，其实这往往就是噩梦的开始。在遵循标准的任何Web文档中，DOCTYPE都是一项必需的元素。它会影响代码验证，并决定了浏览器最终如何显示你的web文档。为了避免DOCTYPE的问题重复出现，我根据手头的资料整理了这篇文档，以备自己及有兴趣的朋友参考。

在默认情况下，FF和IE的解释标准是不一样的，也就是说，如果一个网页没有声明DOCTYPE，它就会以默认的DOCTYPE解释下面的HTML。在同一种标准下，不同浏览器的解释模型都有所差异，如果声明标准不同，不用我说，您自己想就可以了。学习网页标准，浏览器兼容，从哪里开始您自己决定，但是，请认识DOCTYPE：

一、什么是DOCTYPE

DOCTYPE是Document Type（文档类型）的简写，在页面中，用来指定页面所使用的XHTML（或者HTML）的版本。要想制作符合标准的页面，一个必不可少的关键组成部分就是DOCTYPE声明。只有确定了一个正确的DOCTYPE，XHTML里的标识和CSS才能正常生效。

二、DOCTYPE的规则

DOCTYPE声明的写法遵循一定的规则，它指出阅读程序应该用什么规则集来解释文档中的标记。在Web文档的情况下，“阅读程序”通常是浏览器或者校验器这样的一个程序，“规则”则是w3c所发布的一个文档类型定义（dtd）中包含的规则。
每个dtd都包括标记、attributes、properties等内容，它们用于标记web文档的内容；此外还包括一些规则，它们规定了哪些标记能出现在其他哪些标记中。每个web建议标准（比如html 4 frameset和xhtml 1.0 transitional）都有自己的dtd。

以下是从手册上摘抄的规则：

语法：

HTML  顶级元素  可用性 "注册//组织//类型 标签//定义  语言""URL"

可能值：

- 顶级元素：指定 DTD 中声明的顶级元素类型。这与声明的 SGML 文档类型相对应。 HTML 默认。HTML。
- 可用性：指定正式公开标识符(FPI)是可公开访问的对象还是系统资源。 PUBLIC 默认。可公开访问的对象。SYSTEM 系统资源，如本地文件或 URL。
- 注册：指定组织是否由国际标准化组织(ISO)注册。 + 默认。组织名称已注册。
- 组织名称未注册。Internet 工程任务组(IETF)和万维网协会(W3C)并非注册的 ISO 组织。
组织：指定表明负责由 !DOCTYPE 声明引用的 DTD 的创建和维护的团体或组织的名称，即 OwnderID。 IETF IETF。 W3C W3C。
- 类型：指定公开文本类，即所引用的对象类型。 DTD 默认。DTD。
- 标签：指定公开文本描述，即对所引用的公开文本的唯一描述性名称。后面可附带版本号。 HTML 默认。HTML。
- 定义：指定文档类型定义。
　　Frameset 框架集文档。
　　Strict 排除所有 W3C 专家希望逐步淘汰的代表性属性和元素，因为样式表已经很完善了。
　　Transitional 包含除 frameSet 元素的全部内容。
- 语言：指定公开文本语言，即用于创建所引用对象的自然语言编码系统。该语言定义已编写为 ISO 639  语言代码(大写两个字母)。 EN 默认。英语。
- URL：指定所引用对象的位置

为了获得正确的DOCTYPE声明，关键就是让dtd与文档所遵循的标准对应。例如，假定文档遵循的是xhtml 1.0 strict标准，文档的doctype声明就应该引用相应的dtd。另一方面，如果doctype声明指定的是xhtml dtd，但文档包含的是旧式风格的html标记，就是不恰当的；类似地，如果doctype声明指定的是html dtd，但文档包含的是xhtml 1.0 strict标记，同样是不恰当的。

三、选择什么样的DOCTYPE

如上例所示，XHTML 1.0中有3种DTD（文档类型定义）声明可以选择：过渡的（Transitional）、严格的（Strict）和框架的（Frameset）。这里分别介绍如下。

1．过渡的

一种要求不很严格的DTD，允许在页面中使用HTML4.01的标识（符合xhtml语法标准）。过渡的DTD的写法如下：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

2．严格的

一种要求严格的DTD，不允许使用任何表现层的标识和属性，例如<br/>等。严格的DTD的写法如下：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

3．框架的

一种专门针对框架页面所使用的DTD，当页面中含有框架元素时，就要采用这种DTD。框架的DTD的写法如下：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

使用严格的DTD来制作页面，当然是最理想的方式。但是，对于没有深入了解Web标准的网页设计者，比较合适的是使用过渡的DTD。因为这种DTD还允许使用表现层的标识、元素和属性，比较适合大多数网页制作人员。

四、需要注意的问题

没什么特别的，就是一定要将DOCTYPE声明放在XHTML文档的顶部，上面哪怕多个HTML注释标记都不行。

最好示例代码也加上DOCTYPE，否则效果会有差异。

本文转载自：http://www.blueidea.com/tech/web/2007/5172.asp

• 首次被JSTL 1.0引入的EL现在被合并到JSP规范中，就像应用template text一样地使用所有的标准的和定制的组件。
• 新的EL已经被扩展，具备一个函数调用机制，JSTL1.1整合了一系列经常需要使用的函数。
• 新增加的变量和servlet 规范定义的错误处理机制被更好地组织起来。通过新增加的变量，JSP error pages 现在可以提供更多的错误信息。
• 容器因为更加严格的语法检查可以更容易地找出发生的错误。
• 所有的J2EE 1.4规范（包括JSP 2.0 和 Servlet 2.4），为了声明部署的规则描述而应用了XML schema。这样的好处之一是你现在可以通过任何顺序列出web.xml文件中的描述。JSP 2.0也增加了一些新的配置选项用于部署描述，允许通过全局的配置来代替基于每页的配置。
• 由于更具伸缩性的规则和新的自定义action element，现在就像编写XML文件一样，编写JSP页面变得更加容易。
• 定制的标签库现在可以开发成一系列的标签文件（具有JSP元素的文本文件），标签处理器可以使用新的、简化的标签处理器的API。与此同时，新规范加入了一些新的特性，比如：支持在jsp页面上显示动态属性列表和可执行片断属性。

在众多的书籍中，这是头一个讲解JSP 2.0新特性的文章。在这一部分，我们将看到和EL相关的信息，其他的新特性留到后面。在这里我假定读者已经熟悉JSP 1.2，而且至少听说过JSTL。

你可能对这本第三版的《JavaServer Pages》感兴趣。这本书中，我尽可能在细节上讲述所有的内容，而且并不认为你对JSP或者JSTL了解一切。这本书预计在2003年12月 出版，但是你现在可以在http://www.amazon.com、Barnes&Noble，或者其他在线书店预订。

EL(The Expression Language)

如果过去使用过JSTL，那么你可能已经熟悉 了EL。EL在JSTL 1.0规范中被引入，用来在运行期间对Java表达式中action element属性赋值提供另一种选择。当JSTL EL已经非常迅速的流行起来情况下，还是存在一个问题： JSTL EL 表达式仅仅可以与JSTL和custom action一起使用，怎样才能使用非标准API对EL表达式求值？

JSP 2.0中,JSP容器自己可以理解EL表达式。这使你在所有过去只能应用Java表达式的地方应用EL表达式成为可能，比如：标准和定制action的属性值，模板文本。

在我们看具体的例子前，让我们更进一步的看看 什么是EL。EL是从JavaScript中获得启发的一种语言，XPath(一种用来访问XML文档的语言)，但是EL在对变量的null值和执行更多 数据类型的自动类型转换的处理上更加宽松。这些新特性对于web应用非常重要，在这些应用中输入通常通过html表单的request parameter来得到。这些参数可能仅仅在某些请求下才能体现出来，而且浏览器经常将request parameter作为文本发送，然而应用程序经常需要把他们作为数字类型、布尔类型（true 或者 false）来使用。通过EL，你根本就很少需要关心缺少某些参数的值或者类型转换。

一个EL表达式包含变量和操作符。任何存储在某个JSP作用范围(如：page、 request、session、application)的bean能被作为一个EL变量来使用。另外，EL支持以下预定义的变量：

操作符描述了你对变量所期望的操作。如果你之前曾经使用过任何编程语言的话，在EL表达式中所使用的操作符对你来说可能看起来很熟悉。因为它们和那些在大多数语言中所支持的操作符一样。

一个EL表达式可以包含：数字、文本（在单引号或者双引号之间）、布尔值、null值。

因为一个EL表达式可以出现在静态文本出现的 地方，因此你必须告诉JSP容器它应该被当作一个EL表达式来处理。你可以通过使用定界符来做到这一点。一个EL表达式总是以”${ }”来标记（一个“$”符号和一个左花括号,右花括号）。这里有一个EL表达式，它将一个命名为amount的变量加5：

${amount + 5}

如果你想要将5加到一个bean的property上，可以使用property访问操作符：

${order.amount + 5}

在当前这个指定的bean或者collection集合中，Property访问操作符（一个“.“符号）告诉EL去寻找名字为amount的property。

${order['amount'] + 5}

在[]之间的值必须是一个property的名字（就像上面的例子中那样）或者是一个保存property名字的变量（或者是一个完整的EL子表达式）。

EL表达式可以被用来赋值给任何标准的或者定制的JSP行为属性（action attribute），这些行为属性被标记为可以接受动态值（或者请求期间的属性值，就象它被正式调用一样）：

<c:out value=”${order.amount + 5}”/>

在JSP 2.0之前，你不得不使用Java表达式去给一个属性动态赋值。在过去的很多年中，这已经成为语法混乱的一个普遍根源。

最后，EL表达式可以在页面中和模板直接混合使用。当你生成HTML并且需要设置一个动态值给一个属性的时候，这非常方便：

<input name=”firstName” value=”${customer.firstName}”>

JSP 1.2中，你不得不使用JSTL的<c:out>来实现同样的事情，最后把各种不同类型的元素混合起来，这导致程序理解起来非常的困难：

<input name=”firstName”

value=”<c:out value=”${customer.firstName}”/>” >

新JSTL 1.1 Tag Library 标识符

JSTL1.1发布的是一个初级的版本，主要 目的是用来整合JSTL和JSP2.0 。最明显的变化是JSTL1.0 “孪生函数库”（一组库用来接受EL表达式，另外一组用来接受JAVA表达式），而它们已经被一组既可以用于EL表达式也可以用于JAVA表达式的函数库 所代替。

在JSTL 1.1中使用以下标识符:

如果你曾经使用过JSTL1.0，你可能会注意到新的标识符和旧的EL库标试符一模一样，除了加入了“/jsp path” element。你也可能注意到在JSTL1.1中有一个库，包含了EL的函数。我们稍后就会看到。

一个新的EL操作符

在JSP页面中一个非常普遍的需求就是：当某 个条件为真时，要在网页中包含一些文字。在JSP1.2和JSTL1.1中，用具有代表性的<c:if>来实现，但是这样做非常繁琐。 JSP2.0增加了一个新的条件操作符用于EL，以更加优雅的方式来处理这样的情况。这个条件操作符存在于很多编程语言中（比 如：Java,C,JavaScript）,因此你可能以前就见过它。它判断一个布尔的条件，当条件为真或者假时，分别取不同的结果。

一个能清楚说明它如何工作的例子：

<select name=”artist”>

<option value=”1″ ${param.artist == 1 ? ‘selected’ : ”}>

Vesica Pisces

<option value=”2″ ${param.artist == 2 ? ‘selected’ : ”}>

Cortical Control

<option value=”3″ ${param.artist == 3 ? ‘selected’ : ”}>

Vida Vierra

</select>

在这里，我使用了EL表达式和条件操作符来选 择是否包含 html 中的 “selected”属性，只有符合条件的 “option” 才被添加 “selected” 属性。如果条件（param.artist==1）为真时，前面的“selected” 才被添加到网页中；否则就添加后面的（在这里是空字符串 ‘’）到页面中。

EL函数

当EL从JSTL规范中移到JSP规范中，它使用了一个如何进行函数调用的技巧。这个EL函数语法非常简单：方法名，紧接着在圆括号中有一组参数：<%@ taglib prefix=”fn”

uri=”http://java.sun.com/jsp/jstl/functions” %>

${fn:length(myCollection)}

这是一个属于标签库中的函数,并且函数名字在页面中所包含的前缀要指定taglib库。在这个例子中，我使用了前缀fn,这是JSTL function库默认的前缀。

标签库描述符（Tag Library Descriptor,TLD）将函数名称映射到一个由JAVA实现的静态方法中：<function>

<description>

Returns the number of items in a collection or the number of characters in a string.

</description>

<name>length</name>

<function-class>

org.apache.taglibs.standard.functions.Functions

</function-class>

<function-signature>

int length(java.lang.Object)

</function-signature>

</function>

在这里最有趣的element 是<function-signature>。它包含一个函数返回类型的声明，静态的方法的名字，在圆括号中声明该方法所有参数的类型（可以 没有参数或者有多个，参数间用逗号间隔开）。返回值类型和参数类型必须是java的原始类型（Object）或者是其他合法类型。

这个静态方法 length()在Jakarta Taglibs标准库中用类似于下面的代码实现的：

1
            2
            3
            4
            5
            6
            7
            8
            9
            10
            11
            12
            13
            14
            15
            16
            17
            18
            19
            20
            21
            22
            23
            24
            25
            26
            27
            28
            29
            30
            31
            32
            33
            34
            35
            36
            37
            38
            39
            40
            41
            42
            43
            44
            45
            46
            47
            48
            49
            50
            51
            52
            53
            54
            55
            56
            57
            58
            59
            60
            61
            62
            63
            64
            65
            66
            67
            68
            69
            

public static int length(Object obj)
             
            throws JspTagException {
             
            if (obj == null)
             
            return 0;
             
            if (obj instanceof String)
             
            return ((String)obj).length();
             
            if (obj instanceof Collection)
             
            return ((Collection)obj).size();
             
            if (obj instanceof Map)
             
            return ((Map)obj).size();
             
            int count = 0;
             
            if (obj instanceof Iterator) {
             
            Iterator iter = (Iterator) obj;
             
            count = 0;
             
            while (iter.hasNext()) {
             
            count++;
             
            iter.next();
             
            }
             
            return count;
             
            }
             
            if (obj instanceof Enumeration) {
             
            Enumeration enum = (Enumeration) obj;
             
            count = 0;
             
            while (enum.hasMoreElements()) {
             
            count++;
             
            enum.nextElement();
             
            }
             
            return count;
             
            }
             
            try {
             
            count = Array.getLength(obj);
             
            return count;
             
            } catch (IllegalArgumentException ex) {}
             
            throw new JspTagException("Unsupported type"));
             
            }

就像你所看到的，在那里没有什么出奇的地方。它是一个常规的静态方法，这个函数中通过对运行期中的参数类别的判断，找出参数的长度。

除了在这个方法中使用的length()方法，JSTL1.1标签库还包含了许多其它经常使用的函数：

在JSP中使用标签是很平常的事情，在制作自定义变迁时，通常都需要写tld文件来定义变迁的各种属性，对应的java类，前缀等等。标签与tld文件紧紧相连，那么，到底应该怎么放置tld文件？在web.xml中怎么定义tld文件的位置？

以下是具体的分析

Ø  Taglib的使用：

首先是在头部申明taglib, uri必须是web.xml定义的，或者是原始tld文件定义的。

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

<%@ taglib prefix="ex" uri="/jstl-examples-taglib" %>

然后便可以在jsp页面中通过prefix使用相应的标签

<c:import varReader="reader" url="${filepath}">

  <ex:escapeHtml reader="${reader}"/>

</c:import>

Ø  Uri与tld文件的映射关系

JSP文件中使用的标签通常都有一个tld定义文件(标签库定义文件，主要定义标签对应的java类，标签的属性等等信息)与之对应的,web容器需要找到相应的tld文件，以tld文件中定义的内容判断标签的使用是否正确。

Web做【使用正确性】判断处理，当遇到类似【<c:import】这样的标签时，会通过prefix定位到uri，再根据uri定位到相应的tld文件，对tld文件进行解析。其中urißàtld文件的映射关系如下：

Key

（Uri）
 Value

（String[] taglib_tld_location）
 
Taglib-URI：

(如/jstl-examples-taglib、http://java.sun.com/jstl/core等)
 taglib_tld_location[0]
 
taglib_tld_location[1]
 

本文主要介绍的便是uri到tld的映射

Ø  Tld文件路径定义方式

如下方式1和方式2只能在2.3版本使用，Servlet2.4开始便不能在web.xml中定义taglib了。

<!DOCTYPE web-app

    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

    "http://java.sun.com/dtd/web-app_2_3.dtd">

l  方式1：

如下所示，在web.xml中定义

    <taglib>

        <taglib-uri>/jstl-examples-taglib</taglib-uri>

        <taglib-location>/WEB-INF/lib/jstl-examples.tld</taglib-location>

</taglib>

如果这样定义的话，映射关系便如下：

/jstl-examples-taglibßà{“/WEB-INF/lib/jstl-examples.tld”,””} // taglib_tld_location[0]就足以表示tld路径，因此taglib_tld_location[1]为空。

l  方式2：

如下所示，在web.xml中定义

    <taglib>

        <taglib-uri>/jstl-examples-taglib</taglib-uri>

        <taglib-location>/WEB-INF/lib/ jstl-examples.jar</taglib-location>

</taglib>

如果这样定义的话，映射关系便如下：

/jstl-examples-taglibßà{“/WEB-INF/lib/ jstl-examples.jar”,” META-INF/taglib.tld”}

 // taglib_tld_location[0]表示jar路径，taglib_tld_location[1]固定为META-INF/taglib.tld(也就是说，tld在jar文件中的保存路径必须是META-INF/taglib.tld，名称必须是taglib.tld)。这就是说一个jar里只能有一个tld。如果代码中不固定为taglib.tld的话，也很难处理，因为如果tld的名称可以随便定义的话，出现多个tld在jar文件中时将会导致混乱。

l  方式3：

不需要在web.xml中定义，只需要把tld保存在web应用能够使用的jar文件中的META-INF路径下便可。这种情况的机制是这样的：web容器会遍历当前web应用能够访问的jar文件，从jar文件中查找META-INF/xxx.tld文件，当找到一个tld文件之后，便会解析tld文件，取出<taglib>节点的<uri>值，把uri作为key值生成映射关系。

如下所示的jstl的core标签库的tld文件，便会有如下的映射关系

http://java.sun.com/jstl/coreßà{“tld文件所在的jar文件的路径”,” META-INF/xxx.tld”}//taglib_tld_location[0]表示jar路径，taglib_tld_location[1]为所搜到的tld在jar文件中的相对路径

……

<taglib>

  <tlib-version>1.0</tlib-version>

  <jsp-version>1.2</jsp-version>

  <short-name>c</short-name>

  <uri>http://java.sun.com/jstl/core</uri>

  <display-name>JSTL core</display-name>

  <description>JSTL 1.0 core library</description>

……

  <tag>

    <name>catch</name>

    <tag-class>org.apache.taglibs.standard.tag.common.core.CatchTag</tag-class>

    <body-content>JSP</body-content>

    <description>

        Catches any Throwable that occurs in its body and optionally

        exposes it.

    </description>

    <attribute>

        <name>var</name>

        <required>false</required>

        <rtexprvalue>false</rtexprvalue>

    </attribute>

  </tag>

……

Ø  Tld文件的解析逻辑

以jstl为例：

Web容器遇到类似【<c:import】标签时，就会通过在头部中定义的<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>找到uri，再根据此uri便可以定位到taglib_tld_location。当taglib_tld_location[0]不是jar文件时，便直接使用java的FileInputStream读取tld文件；当taglib_tld_location[0]是jar文件时，则会

通过如下代码读取tld文件。

URL jarFileUrl = new URL("jar:" + location[0] + "!/");

ZipEntry jarEntry = jarFile.getEntry(location[1]);

Ø  总结：

Tld的定义可以不在web.xml中定义，这时需要保证tld在web应用能够访问的jar中，并且保存在jar的META-INF目录下。此时JSP直接使用tld中定义的<uri>便可；

如果在web.xml中定义tld的路径的话，可以直接指定tld文件路径，此时要保证tld不在jar包中(比如在WEB-INF目录下)；也可以指定为jar文件路径，此时要保证tld在jar中且路径为META-INF/taglib.tld。

以前用WSAD wizard做的，都可以在JSP页面中解析到EL表达式，当然前提是JSP2.0的情况下。
今天遇到了一个莫名其妙的问题。刚下载Eclipse3.3+MyEclipse6.0体验的过程中，遇上了解析不到EL表达式的问题。经过好几个小时的琢磨终于发现了，给大家share一下：
问题就出在建Web Project的时候web.xml声明上。
web.xml声明部分一般分为如下版本的xsd,
web-app_2_2.xsd
web-app_2_3.xsd
web-app_2_4.xsd
web-app_2_5.xsd

更详细的列出各版本web.xml声明部分吧，如下：
web-app_2_2.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/dtd/web-app_2_2.dtd">

web-app_2_3.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

web-app_2_4.xsd

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.4" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

web-app_2_5.xsd

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee  http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">


确定web.xml里的xsd版本之后一定要在JSP的声明(<%@page %>)部分加一行，如下：
<%@ page isELIgnored="false" %>
这样设为false才能解析EL表达式。
经过各版本的test之后....
注意!! 其中servlets 2.4(我没记错的话JSP 2.0出来之后的第一个版本)，这个版本的isELIgnored默认设置为false。所以使用web.xml里用web-app_2_4.xsd声明的时候在JSP页面不用特意声明。

下面是官方Documention中isELIgnored Attribute的详解：
The isELIgnored Attribute
• Format
– <%@ page isELIgnored="false" %>
– <%@ page isELIgnored="true" %>
Purpose
– To control whether the JSP 2.0 Expression Language
(EL) is ignored (true) or evaluated normally (false).
• Notes
– If your web.xml specifies servlets 2.3 (corresponding to
JSP 1.2) or earlier, the default is true
• But it is still legal to change the default—you are permitted
to use this attribute in a JSP-2.0-compliant server
regardless of the web.xml version.
– If your web.xml specifies servlets 2.4 (corresponding to
JSP 2.0) or earlier, the default is false

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/qingkangxu/archive/2010/12/05/6057034.aspx

(文：包一磊)

AJAX的出现极大的改变了Web应用客户端的操作模式，它使的用户可以在全心工作时不必频繁的忍受那令人厌恶的页面刷新。理论上AJAX技术在很大的程度上可以减少用户操作的等待时间，同时节约网络上的数据流量。而然，实际情况却并不总是这样。用户时常会抱怨用了AJAX的系统响应速度反而降低了。

笔者从事AJAX方面的研发多年，参与开发了目前国内较为成熟的AJAX平台-dorado。根据笔者的经验，导致这种结果的根本原因并不在AJAX。很多时候系统响应速度的降低都是由不够合理的界面设计和不够高效的编程习惯造成的。下面我们就来分析几个AJAX开发过程中需要时刻注意的环节。

n 合理的使用客户端编程和远程过程调用。

客户端的编程主要都是基于JavaScript的。而JavaScript是一种解释型的编程语言，它的运行效率相对于Java等都要稍逊一筹。同时JavaScript又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻辑可以在客户端执行应该有一个清醒的认识。

在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：

u 尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。

u 如果可能的话尽可能使用AJAX方式的远程过程调用（异步方式的远程过程调用）。

u 避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。

n 改进对DOM对象的操作方式。

客户端的编程中，对DOM对象的操作往往是最容易占用CPU时间的。而对于DOM对象的操作，不同的编程方法之间的性能差异又往往是非常大的。

以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个10x1000的表格。然而它们的运行速度却有着天壤之别。

这里的“测试代码1”和“测试代码2”之间的差别在于在创建表格单元时使用了不同的API方法。而“测试代码2”和“测试代码3”之间的差别在于处理顺序的略微不同。

“测试代码1”和“测试代码2”之间如此大的性能差别我们无从分析，目前所知的是insertRow和insertCell是DHTML中表格特有的API，createElement和appendChild是W3C DOM的原生API。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为DOM的原生API总是优于对象特有的API。建议大家在需要频繁调用某一API时，对其性能表现做一些基本的测试。

“测试代码2”和“测试代码3”之间的性能差异主要来自于他们的构建顺序不同。“测试代码2”的做法是首先创建最外层的<TABLE>对象，然后再在循环中依次创建<TR>和<TD>。而“测试代码3”的做法是首先在内存中由内到外的构建好整个表格，最后再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行appendChild越好。有时为了提高运行效率，我们甚至可以考虑先使用removeChild将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。

n 提高字符串累加的速度

在使用AJAX提交信息时，我可能常常需要拼装一些比较大的字符串通过XmlHttp来完成POST提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我们可能不得不面对这样的需求。那么JavaScript中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为30000的字符串。

这段代码耗时14.325秒，结果并不理想。现在我们将代码改为如下的形式：

这段代码耗时0.359秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时0.140秒。

不过，上面这种做法也许并不是最好的！如果我们需要提交的信息是XML格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成XML格式），我们还能找到更高效更优雅的方法—利用DOM对象为我们组装字符串。下面这段代买组装一个长度为950015的字符串仅须耗时0.890秒。

n 避免DOM对象的内存泄漏。

关于IE中DOM对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重的！它会导致IE的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。

比较常见的内存泄漏的模型有“循环引用模型”、“闭包函数模型”和“DOM插入顺序模型”,对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式来避免。而对于“DOM插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。

有关内存泄漏的模型的更多介绍可以通过Google很快的查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具—Drip，目前的较新版本是0.5，下载地址是http://outofhanwell.com/ieleak/index.php

n 复杂页面的分段装载和初始化

对系统当中某些确实比较复杂而又不便使用IFrame的界面，我们可以对其实施分段装载。例如对于多页标签的界面，我们可以首先下载和初始化多页标签的默认页，然后利用AJAH（asynchronous JavaScript and HTML）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在第一时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。

n 利用GZIP压缩网络流量。

除了上面提到的这些代码级的改良之外，我们还可以利用GZIP来有效的降低网络流量。目前常见的主流浏览器已经全部支持GZIP算法，我们往往只需要编写少量的代码就可以支持GZIP了。例如在J2EE中我们可以在Filter中通过下面的代码来判断客户端浏览器是否支持GZIP算法，然后根据需要利用java.util.zip.GZIPOutputStream来实现GZIP的输出。

一般而言，GZIP对于HTML、JSP的压缩比可以达到80%左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略的。结合其他因素，支持GZIP的网站有可能为我们节约50%的网络流量。因此GZIP的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用Http的监视工具Fiddler可以方便的检测出网页在使用GZIP前后的通讯数据量。Fiddler的下载地址是http://www.fiddlertool.com/fiddler/

关于Web应用的性能优化其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对Web应用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇的性能提升。

作者： KeeKim Heng, Google Web Developer

在我们开发互联网富应用（RIA）时，我们经常写一些javascript脚本来修改或者增加页面元素，这些工作最终是DOM——或者说文档对象模型——来完成的，而我们的实现方式会影响到应用的响应速度。

DOM操作会导致浏览器重解析(reflow)，这是浏览器的一个决定页面元素如何展现的计算过程。直接修改DOM，修改元素的CSS样式，修改浏览器的窗口大小，都会触发重解析。读取元素的布局属性比如offsetHeithe或者offsetWidth也会触发重解析。重解析需要花费计算时间，因此重解析触发的越少，应用就会越快。

DOM操作通常要不就是修改已经存在的页面上的元素，要不就是创建新的页面元素。下面的4种优化方案覆盖了修改和创建DOM节点两种方式，帮助你减少触发浏览器重解析的次数。

方案一：通过CSS类名切换来修改DOM

这个方案让我们可以一次性修改一个元素和它的子元素的多个样式属性而只触发一次重解析。

需求：

（emu注：原文作者写到这里的时候脑子显然短路了一下，把后面的Out-of-the-flow DOM Manipulation模式要解决的问题给摆到这里来了，不过从示范代码中很容易明白作者真正想描述的问题，因此emu就不照翻原文了）

我们现在需要写一个函数来修改一个超链接的几个样式规则。要实现很简单，把这几个规则对应的属性逐一改了就好了。但是带来的问题是，每修改一个样式属性，都会导致一次页面的重解析。

view plaincopy to clipboardprint?
function selectAnchor(element) {  
  element.style.fontWeight = 'bold';  
  element.style.textDecoration = 'none';  
  element.style.color = '#000';  
} 
function selectAnchor(element) {
  element.style.fontWeight = 'bold';
  element.style.textDecoration = 'none';
  element.style.color = '#000';
}

解决方案

要解决这个问题，我们可以先创建一个样式名，并且把要修改的样式规则都放到这个类名上，然后我们给超链接添加上这个新类名，就可以实现添加几个样式规则而只触发一次重解析了。这个模式还有个好处是也实现了表现和逻辑相分离。

view plaincopy to clipboardprint?
.selectedAnchor {  
  font-weight: bold;  
  text-decoration: none;  
  color: #000;  
}  
 
function selectAnchor(element) {  
  element.className = 'selectedAnchor';  
} 
.selectedAnchor {
  font-weight: bold;
  text-decoration: none;
  color: #000;
}

function selectAnchor(element) {
  element.className = 'selectedAnchor';
}

 方案二：在非渲染区修改DOM

（emu注：作者在这里再次脑子短路，把DocumentFragment DOM Generation模式的介绍提前到这里来了，emu只好再次发挥一下）
上一个方案解决的是修改一个超链接的问题，当一次需要对很多个超链接进行相同修改的时候，这个方案就可以大显身手了。

需求

需求是这样的，我们要写一个函数来修改一个指定元素的子元素中所有的超链接的样式名（className）属性。要实现很简单，我们可以通过遍历每个超链接并且修改它们的样式名来完成任务。但是带来的问题就是，每修改一个超链接都会导致一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
} 
function updateAllAnchors(element, anchorClass) {
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
}
 

解决方案

要解决这个问题，我们可以把被修改的指定元素从DOM里面移除，再修改所有的超链接，然后在把这个元素插入回到它原来的位置上。为了完成这个复杂的操作，我们可以先写一个可重用的函数，它不但移除了这个DOM节点，还返回了一个把元素插回到原来的位置的函数。

view plaincopy to clipboardprint?
/** 
 * Remove an element and provide a function that inserts it into its original position 
 * @param element {Element} The element to be temporarily removed 
 * @return {Function} A function that inserts the element into its original position 
 **/ 
function removeToInsertLater(element) {  
  var parentNode = element.parentNode;  
  var nextSibling = element.nextSibling;  
  parentNode.removeChild(element);  
  return function() {  
    if (nextSibling) {  
      parentNode.insertBefore(element, nextSibling);  
    } else {  
      parentNode.appendChild(element);  
    }  
  };  
} 
/**
 * Remove an element and provide a function that inserts it into its original position
 * @param element {Element} The element to be temporarily removed
 * @return {Function} A function that inserts the element into its original position
 **/
function removeToInsertLater(element) {
  var parentNode = element.parentNode;
  var nextSibling = element.nextSibling;
  parentNode.removeChild(element);
  return function() {
    if (nextSibling) {
      parentNode.insertBefore(element, nextSibling);
    } else {
      parentNode.appendChild(element);
    }
  };
}

有了上面这个函数，现在我们就可以在一个不需要解析渲染的元素上面修改那些超链接了。这样只在移除和插入元素的时候各触发一次重解析。

view plaincopy to clipboardprint?
function updateAllAnchors(element, anchorClass) {  
  var insertFunction = removeToInsertLater(element);  
  var anchors = element.getElementsByTagName('a');  
  for (var i = 0, length = anchors.length; i < length; i ++) {  
    anchors[i].className = anchorClass;  
  }  
  insertFunction();  
} 
function updateAllAnchors(element, anchorClass) {
  var insertFunction = removeToInsertLater(element);
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
  insertFunction();
}
 

方案三：一次性的DOM元素生成

这个方案让我们创建一个元素的过程只触发一次重解析。在创建完元素以后，先进行所有需要的修改，最后才把它插入到DOM里面去就可以了

需求

需求是这样的，实现一个函数，往一个指定的父元素上插入一个超链接元素。这个函数要同时可以设置这个超链接的显示文字和样式类。我们可以这样做：创建元素，插入到DOM里面，然后设置相应的属性。这就要触发3次重解析。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  parentElement.appendChild(element);  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  parentElement.appendChild(element);
  element.innerHTML = anchorText;
  element.className = anchorClass;
}
 

解决方案

很简单，我们只要把插入元素这个操作放到最后做，就可以只进行一次重解析了。

view plaincopy to clipboardprint?
function addAnchor(parentElement, anchorText, anchorClass) {  
  var element = document.createElement('a');  
  element.innerHTML = anchorText;  
  element.className = anchorClass;  
  parentElement.appendChild(element);  
} 
function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  element.innerHTML = anchorText;
  element.className = anchorClass;
  parentElement.appendChild(element);
}

不过，要是我们想要插入很多个超链接到一个元素里面的话，那么这个做法还是有问题：每插入一个超链接还是要触发一次重解析。下一个方案可以解决这个问题。

方案四：通过文档片段对象（DocumentFragment）创建一组元素

这个方案允许我们创建并插入很多个元素而只触发一次重解析。要实现这点需要用到所谓的文档片段对象（DocumentFragment）。我们先在DOM之外创建一个文档片段对象（这样它也就不需要解析和渲染），然后我们在文档片段对象中创建很多个元素，最后我们把这个文档片段对象中所有的元素一次性放到DOM里面去，只触发一次重解析。

需求

我们要写一个函数，往一个指定的元素上面增加10个超链接。如果我们简单的直接插入10个超链接到元素上面，就会触发10次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor;  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    element.appendChild(anchor);  
  }  
} 
function addAnchors(element) {
  var anchor;
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    element.appendChild(anchor);
  }
}

解决方案

要解决这个问题，我们要先创建一个文档片段对象，然后把每个新创建的超链接都插入到它里面去。当我们把文档片段对象用appendChild命令插入到指定的节点时，这个文档片段对象的所有子节点就一起被插入到指定的元素里面，而且只需要触发一次重解析。

view plaincopy to clipboardprint?
function addAnchors(element) {  
  var anchor, fragment = document.createDocumentFragment();  
  for (var i = 0; i < 10; i ++) {  
    anchor = document.createElement('a');  
    anchor.innerHTML = 'test';  
    fragment.appendChild(anchor);  
  }  
  element.appendChild(fragment);  
} 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/emu/archive/2010/03/01/5334583.aspx

2007 年 8 月 31 日

很多应用譬如监控、即时通信、即时报价系统都需要将后台发生的变化实时传送到客户端而无须客户端不停地刷新、发送请求。本文首先介绍、比较了常用的“服务器推”方案，着重介绍了 Comet － 使用 HTTP 长连接、无须浏览器安装插件的两种“服务器推”方案：基于 AJAX 的长轮询方式；基于 iframe 及 htmlfile 的流方式。最后分析了开发 Comet 应用需要注意的一些问题，以及如何借助开源的 Comet 框架－pushlet 构建自己的“服务器推”应用。
“服务器推”技术的应用

 请访问 Ajax 技术资源中心，这是有关 Ajax 编程模型信息的一站式中心，包括很多文档、教程、论坛、blog、wiki 和新闻。任何 Ajax 的新信息都能在这里找到。 
   订阅 Ajax 相关文章和教程的 RSS 提要
 

 
 
传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：

监控系统：后台硬件热插拔、LED、温度、电压发生变化；
即时通信系统：其它用户登录、发送信息；
即时报价系统：后台数据库内容发生变化；
这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：

客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。
客户与服务器端通信的信息格式，采取怎样的出错处理机制。
客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。
 
  回页首
 
基于客户端套接口的“服务器推”技术

Flash XMLSocket

如果 Web 应用的用户接受应用只有在安装了 Flash 播放器才能正常运行， 那么使用 Flash 的 XMLSocket 也是一个可行的方案。

这种方案实现的基础是：

Flash 提供了 XMLSocket 类。
JavaScript 和 Flash 的紧密结合：在 JavaScript 可以直接调用 Flash 程序提供的接口。
具体实现方法：在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。

关于如何去构建充当了 JavaScript 与 Flash XMLSocket 桥梁的 Flash 程序，以及如何在 JavaScript 里调用 Flash 提供的接口，我们可以参考 AFLAX（Asynchronous Flash and XML）项目提供的 Socket Demo 以及 SocketJS（请参见 参考资源）。

Javascript 与 Flash 的紧密结合，极大增强了客户端的处理能力。从 Flash 播放器 V7.0.19 开始，已经取消了 XMLSocket 的端口必须大于 1023 的限制。Linux 平台也支持 Flash XMLSocket 方案。但此方案的缺点在于：

客户端必须安装 Flash 播放器；
因为 XMLSocket 没有 HTTP 隧道功能，XMLSocket 类不能自动穿过防火墙；
因为是使用套接口，需要设置一个通信端口，防火墙、代理服务器也可能对非 HTTP 通道端口进行限制；
不过这种方案在一些网络聊天室，网络互动游戏中已得到广泛使用。

Java Applet 套接口

在客户端使用 Java Applet，通过 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立与服务器端的套接口连接，从而实现“服务器推”。

这种方案最大的不足在于 Java applet 在收到服务器端返回的信息后，无法通过 JavaScript 去更新 HTML 页面的内容。

 
  回页首
 
基于 HTTP 长连接的“服务器推”技术

Comet 简介

浏览器作为 Web 应用的前台，自身的处理功能比较有限。浏览器的发展需要客户端升级软件，同时由于客户端浏览器软件的多样性，在某种意义上，也影响了浏览器新技术的推广。在 Web 应用中，浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果，通过在浏览器端发送异步请求，提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统，对任何用户来说，可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中，将更新的信息实时传送给客户端，从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。

图 1. 传统的 Web 应用模型与基于 AJAX 的模型之比较 
“服务器推”是一种很早就存在的技术，以前在实现上主要是通过客户端的套接口，或是服务器端的远程调用。因为浏览器技术的发展比较缓慢，没有为“服务器推”的实现提供很好的支持，在纯浏览器的应用中很难有一个完善的方案去实现“服务器推”并用于商业程序。最近几年，因为 AJAX 技术的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 组件中可以解决 IE 的加载显示问题，一些受欢迎的应用如 meebo，gmail+gtalk 在实现中使用了这些新技术；同时“服务器推”在现实应用中确实存在很多需求。因为这些原因，基于纯浏览器的“服务器推”技术开始受到较多关注，Alex Russell（Dojo Toolkit 的项目 Lead）称这种基于 HTTP 长连接、无须在浏览器端安装插件的“服务器推”技术为“Comet”。目前已经出现了一些成熟的 Comet 应用以及各种开源框架；一些 Web 服务器如 Jetty 也在为支持大量并发的长连接进行了很多改进。关于 Comet 技术最新的发展状况请参考关于 Comet 的 wiki。

下面将介绍两种 Comet 应用的实现模型。

基于 AJAX 的长轮询（long-polling）方式

如 图 1 所示，AJAX 的出现使得 JavaScript 可以调用 XMLHttpRequest 对象发出 HTTP 请求，JavaScript 响应处理函数根据服务器返回的信息对 HTML 页面的显示进行更新。使用 AJAX 实现“服务器推”与传统的 AJAX 应用不同之处在于：

服务器端会阻塞请求直到有数据传递或超时才返回。
客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。
图 2. 基于长轮询的服务器推模型 
一些应用及示例如 “Meebo”, “Pushlet Chat” 都采用了这种长轮询的方式。相对于“轮询”（poll），这种长轮询方式也可以称为“拉”（pull）。因为这种方案基于 AJAX，具有以下一些优点：请求异步发出；无须安装插件；IE、Mozilla FireFox 都支持 AJAX。

在这种长轮询方式下，客户端是在 XMLHttpRequest 的 readystate 为 4（即数据传输结束）时调用回调函数，进行信息处理。当 readystate 为 4 时，数据传输结束，连接已经关闭。Mozilla Firefox 提供了对 Streaming AJAX 的支持， 即 readystate 为 3 时（数据仍在传输中），客户端可以读取数据，从而无须关闭连接，就能读取处理服务器端返回的信息。IE 在 readystate 为 3 时，不能读取服务器返回的数据，目前 IE 不支持基于 Streaming AJAX。

基于 Iframe 及 htmlfile 的流（streaming）方式

iframe 是很早就存在的一种 HTML 标记， 通过在 HTML 页面里嵌入一个隐蔵帧，然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求，服务器端就能源源不断地往客户端输入数据。

图 3. 基于流方式的服务器推模型 
上节提到的 AJAX 方案是在 JavaScript 里处理 XMLHttpRequest 从服务器取回的数据，然后 Javascript 可以很方便的去控制 HTML 页面的显示。同样的思路用在 iframe 方案的客户端，iframe 服务器端并不返回直接显示在页面的数据，而是返回对客户端 Javascript 函数的调用，如“<script type="text/javascript">js_func(“data from server ”)</script>”。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递；客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

从 图 3 可以看到，每次数据传送不会关闭连接，连接只会在通信出现错误时，或是连接重建时关闭（一些防火墙常被设置为丢弃过长的连接， 服务器端可以设置一个超时时间， 超时后通知客户端重新建立连接，并关闭原来的连接）。

使用 iframe 请求一个长连接有一个很明显的不足之处：IE、Morzilla Firefox 下端的进度栏都会显示加载没有完成，而且 IE 上方的图标会不停的转动，表示加载正在进行。Google 的天才们使用一个称为“htmlfile”的 ActiveX 解决了在 IE 中的加载显示问题，并将这种方法用到了 gmail+gtalk 产品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介绍了这种方法。Zeitoun 网站提供的 comet-iframe.tar.gz，封装了一个基于 iframe 和 htmlfile 的 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器，可以作为参考。（请参见 参考资源）

 
  回页首
 
使用 Comet 模型开发自己的应用

上面介绍了两种基于 HTTP 长连接的“服务器推”架构，更多描述了客户端处理长连接的技术。对于一个实际的应用而言，系统的稳定性和性能是非常重要的。将 HTTP 长连接用于实际应用，很多细节需要考虑。

不要在同一客户端同时使用超过两个的 HTTP 长连接

我们使用 IE 下载文件时会有这样的体验，从同一个 Web 服务器下载文件，最多只能有两个文件同时被下载。第三个文件的下载会被阻塞，直到前面下载的文件下载完毕。这是因为 HTTP 1.1 规范中规定，客户端不应该与服务器端建立超过两个的 HTTP 连接， 新的连接会被阻塞。而 IE 在实现中严格遵守了这种规定。

HTTP 1.1 对两个长连接的限制，会对使用了长连接的 Web 应用带来如下现象：在客户端如果打开超过两个的 IE 窗口去访问同一个使用了长连接的 Web 服务器，第三个 IE 窗口的 HTTP 请求被前两个窗口的长连接阻塞。

所以在开发长连接的应用时， 必须注意在使用了多个 frame 的页面中，不要为每个 frame 的页面都建立一个 HTTP 长连接，这样会阻塞其它的 HTTP 请求，在设计上考虑让多个 frame 的更新共用一个长连接。

服务器端的性能和可扩展性

一般 Web 服务器会为每个连接创建一个线程，如果在大型的商业应用中使用 Comet，服务器端需要维护大量并发的长连接。在这种应用背景下，服务器端需要考虑负载均衡和集群技术；或是在服务器端为长连接作一些改进。

应用和技术的发展总是带来新的需求，从而推动新技术的发展。HTTP 1.1 与 1.0 规范有一个很大的不同：1.0 规范下服务器在处理完每个 Get/Post 请求后会关闭套接口连接； 而 1.1 规范下服务器会保持这个连接，在处理两个请求的间隔时间里，这个连接处于空闲状态。 Java 1.4 引入了支持异步 IO 的 java.nio 包。当连接处于空闲时，为这个连接分配的线程资源会返还到线程池，可以供新的连接使用；当原来处于空闲的连接的客户发出新的请求，会从线程池里分配一个线程资源处理这个请求。 这种技术在连接处于空闲的机率较高、并发连接数目很多的场景下对于降低服务器的资源负载非常有效。

但是 AJAX 的应用使请求的出现变得频繁，而 Comet 则会长时间占用一个连接，上述的服务器模型在新的应用背景下会变得非常低效，线程池里有限的线程数甚至可能会阻塞新的连接。Jetty 6 Web 服务器针对 AJAX、Comet 应用的特点进行了很多创新的改进，请参考文章“AJAX，Comet and Jetty”（请参见 参考资源）。

控制信息与数据信息使用不同的 HTTP 连接

使用长连接时，存在一个很常见的场景：客户端网页需要关闭，而服务器端还处在读取数据的堵塞状态，客户端需要及时通知服务器端关闭数据连接。服务器在收到关闭请求后首先要从读取数据的阻塞状态唤醒，然后释放为这个客户端分配的资源，再关闭连接。

所以在设计上，我们需要使客户端的控制请求和数据请求使用不同的 HTTP 连接，才能使控制请求不会被阻塞。

在实现上，如果是基于 iframe 流方式的长连接，客户端页面需要使用两个 iframe，一个是控制帧，用于往服务器端发送控制请求，控制请求能很快收到响应，不会被堵塞；一个是显示帧，用于往服务器端发送长连接请求。如果是基于 AJAX 的长轮询方式，客户端可以异步地发出一个 XMLHttpRequest 请求，通知服务器端关闭数据连接。

在客户和服务器之间保持“心跳”信息

在浏览器与服务器之间维持一个长连接会为通信带来一些不确定性：因为数据传输是随机的，客户端不知道何时服务器才有数据传送。服务器端需要确保当客户端不再工作时，释放为这个客户端分配的资源，防止内存泄漏。因此需要一种机制使双方知道大家都在正常运行。在实现上：

服务器端在阻塞读时会设置一个时限，超时后阻塞读调用会返回，同时发给客户端没有新数据到达的心跳信息。此时如果客户端已经关闭，服务器往通道写数据会出现异常，服务器端就会及时释放为这个客户端分配的资源。
如果客户端使用的是基于 AJAX 的长轮询方式；服务器端返回数据、关闭连接后，经过某个时限没有收到客户端的再次请求，会认为客户端不能正常工作，会释放为这个客户端分配、维护的资源。
当服务器处理信息出现异常情况，需要发送错误信息通知客户端，同时释放资源、关闭连接。
Pushlet - 开源 Comet 框架

Pushlet 是一个开源的 Comet 框架，在设计上有很多值得借鉴的地方，对于开发轻量级的 Comet 应用很有参考价值。

观察者模型

Pushlet 使用了观察者模型：客户端发送请求，订阅感兴趣的事件；服务器端为每个客户端分配一个会话 ID 作为标记，事件源会把新产生的事件以多播的方式发送到订阅者的事件队列里。

客户端 JavaScript 库

pushlet 提供了基于 AJAX 的 JavaScript 库文件用于实现长轮询方式的“服务器推”；还提供了基于 iframe 的 JavaScript 库文件用于实现流方式的“服务器推”。

JavaScript 库做了很多封装工作：

定义客户端的通信状态：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
保存服务器分配的会话 ID，在建立连接之后的每次请求中会附上会话 ID 表明身份；
提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供页面调用；
提供了处理响应的 JavaScript 函数接口 onData()、onEvent()…
网页可以很方便地使用这两个 JavaScript 库文件封装的 API 与服务器进行通信。

客户端与服务器端通信信息格式

pushlet 定义了一套客户与服务器通信的信息格式，使用 XML 格式。定义了客户端发送请求的类型：join、leave、subscribe、unsubscribe、listen、refresh；以及响应的事件类型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。

服务器端事件队列管理

pushlet 在服务器端使用 Java Servlet 实现，其数据结构的设计框架仍可适用于 PHP、C 编写的后台客户端。

Pushlet 支持客户端自己选择使用流、拉（长轮询）、轮询方式。服务器端根据客户选择的方式在读取事件队列（fetchEvents）时进行不同的处理。“轮询”模式下 fetchEvents() 会马上返回。”流“和”拉“模式使用阻塞的方式读事件，如果超时，会发给客户端发送一个没有新信息收到的“heartbeat“事件，如果是“拉”模式，会把“heartbeat”与“refresh”事件一起传给客户端，通知客户端重新发出请求、建立连接。

客户服务器之间的会话管理

服务端在客户端发送 join 请求时，会为客户端分配一个会话 ID， 并传给客户端，然后客户端就通过此会话 ID 标明身份发出 subscribe 和 listen 请求。服务器端会为每个会话维护一个订阅的主题集合、事件队列。

服务器端的事件源会把新产生的事件以多播的方式发送到每个会话（即订阅者）的事件队列里。

 
  回页首
 
小结

本文介绍了如何在现有的技术基础上选择合适的方案开发一个“服务器推”的应用，最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用， 目前开发 Comet 应用还是具有一定的挑战性。

“服务器推”存在广泛的应用需求，为了使 Comet 模型适用于大规模的商业应用，以及方便用户构建 Comet 应用，最近几年，无论是服务器还是浏览器都出现了很多新技术，同时也出现了很多开源的 Comet 框架、协议。需求推动技术的发展，相信 Comet 的应用会变得和 AJAX 一样普及。

参考资料

学习
developerWorks 文章“ 面向 Java 开发人员的 Ajax: 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序”：受异步服务器端事件驱动的 Ajax 应用程序实现较为困难，本文介绍了一种结合使用 Comet 模式和 Jetty 6 Continuations API 的解决方法。
“Comet: Low Latency Data for the Browser”：Alex Russell 是 Dojo Toolkit 的项目主管和 Dojo Foundation 的主席，他在这篇博客文章中提出了 Comet 这个术语。
“What else is burried down in the depth’s of Google’s amazing JavaScript?”（Alex Russel，2006 年 2 月）：Alex 在这篇文章里介绍了如何使用“htmlfile”ActiveX 控件解决 iframe 请求长连接时 IE 的加载显示问题。
Comet wiki：提供了很多开源 Comet 框架的链接。
Jetty：Jetty 是一种开源的基于标准的 Web 服务器，完全使用 Java 语言实现。
“Ajax, Comet and Jetty”（Greg Wilkins，Webtide，2006 年 1 月）：Wilkins 的这份白皮书讨论了扩展 Ajax 连接的 Jetty 架构方法。
Continuations：了解更多关于 Jetty 的 Continuations 特性的信息。
“pushlet”：开源 comet 框架，使用了观察者模型。浏览器端提供了基于 AJAX 和 iframe 的 JavaScript 库，服务器端使用 Java Servlet。
“How to implement COMET with PHP”：提供的 comet-iframe.tar.gz 使用 iframe/htmlfile 封装了一个 JavaScript comet 对象，支持 IE、Mozilla Firefox 浏览器。
“AFLAX”：Asynchronous Flash and XML，提供了强大的 Flash、Javascript 库和很多范例。
developerWorks Ajax 技术资源中心：能找到更多关于 Ajax 技术的文章和教程。
developerWorks Web 开发技术专区：提供了关于 Web 开发和架构方面的大量文章。
developerWorks Java 技术专区：提供了关于 Java 编程各个方面的数百篇文章。
浏览 技术书店，查阅有关本文所述主题以及其他技术主题的书籍。 

1 - Tomcat Server的组成部分
1.1 - Server

A Server element represents the entire Catalina servlet container. (Singleton)

1.2 - Service

A Service element represents the combination of one or more Connector components that share a single Engine
Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求

1.3 - Connector

一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户
TOMCAT有两个典型的Connector，一个直接侦听来自browser的http请求，一个侦听来自其它WebServer的请求
Coyote Http/1.1 Connector 在端口8080处侦听来自客户browser的http请求
Coyote JK2 Connector 在端口8009处侦听来自其它WebServer(Apache)的servlet/jsp代理请求

1.4 - Engine

The Engine element represents the entire request processing machinery associated with a particular Service
It receives and processes all requests from one or more Connectors
and returns the completed response to the Connector for ultimate transmission back to the client
Engine下可以配置多个虚拟主机Virtual Host，每个虚拟主机都有一个域名
当Engine获得一个请求时，它把该请求匹配到某个Host上，然后把该请求交给该Host来处理
Engine有一个默认虚拟主机，当请求无法匹配到任何一个Host上的时候，将交给该默认Host来处理

1.5 - Host

代表一个Virtual Host，虚拟主机，每个虚拟主机和某个网络域名Domain Name相匹配
每个虚拟主机下都可以部署(deploy)一个或者多个Web App，每个Web App对应于一个Context，有一个Context path
当Host获得一个请求时，将把该请求匹配到某个Context上，然后把该请求交给该Context来处理
匹配的方法是“最长匹配”，所以一个path==""的Context将成为该Host的默认Context
所有无法和其它Context的路径名匹配的请求都将最终和该默认Context匹配

1.6 - Context

一个Context对应于一个Web Application，一个Web Application由一个或者多个Servlet组成
Context在创建的时候将根据配置文件＄CATALINA_HOME/conf/web.xml和＄WEBAPP_HOME/WEB-INF/web.xml载入Servlet类
当Context获得请求时，将在自己的映射表(mapping table)中寻找相匹配的Servlet类
如果找到，则执行该类，获得请求的回应，并返回

2 - Tomcat Server的结构图
 
3 - 配置文件＄CATALINA_HOME/conf/server.xml的说明
该文件描述了如何启动Tomcat Server

<!----------------------------------------------------------------------------------------------->

<!-- 启动Server
     在端口8005处等待关闭命令
     如果接受到"SHUTDOWN"字符串则关闭服务器
     -->

<Server port="8005" shutdown="SHUTDOWN" debug="0">

  <!-- Listener ???
       目前没有看到这里
       -->

  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" debug="0"/>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" debug="0"/>

  <!-- Global JNDI resources ???
       目前没有看到这里，先略去
       -->

  <GlobalNamingResources>
    ... ... ... ...
  </GlobalNamingResources>

  <!-- Tomcat的Standalone Service
       Service是一组Connector的集合
       它们共用一个Engine来处理所有Connector收到的请求
       -->

  <Service name="Tomcat-Standalone">

    <!-- Coyote HTTP/1.1 Connector
         className : 该Connector的实现类是org.apache.coyote.tomcat4.CoyoteConnector
         port : 在端口号8080处侦听来自客户browser的HTTP1.1请求
         minProcessors : 该Connector先创建5个线程等待客户请求，每个请求由一个线程负责
         maxProcessors : 当现有的线程不够服务客户请求时，若线程总数不足75个，则创建新线程来处理请求
         acceptCount : 当现有线程已经达到最大数75时，为客户请求排队
                       当队列中请求数超过100时，后来的请求返回Connection refused错误
         redirectport : 当客户请求是https时，把该请求转发到端口8443去
         其它属性略
         -->

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8080"
               minProcessors="5" maxProcessors="75" acceptCount="100"
               enableLookups="true"
               redirectPort="8443"
               debug="0"
               connectionTimeout="20000"
               useURIValidationHack="false"
               disableUploadTimeout="true" />

    <!-- Engine用来处理Connector收到的Http请求
         它将匹配请求和自己的虚拟主机，并把请求转交给对应的Host来处理
         默认虚拟主机是localhost
         -->

    <Engine name="Standalone" defaultHost="localhost" debug="0">
   

      <!-- 日志类，目前没有看到，略去先 -->

      <Logger className="org.apache.catalina.logger.FileLogger" .../>

      <!-- Realm，目前没有看到，略去先 -->

      <Realm className="org.apache.catalina.realm.UserDatabaseRealm" .../>

      <!-- 虚拟主机localhost
           appBase : 该虚拟主机的根目录是webapps/
           它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
           -->

      <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
     

        <!-- 日志类，目前没有看到，略去先 -->

        <Logger className="org.apache.catalina.logger.FileLogger" .../>
     

        <!-- Context，对应于一个Web App
             path : 该Context的路径名是""，故该Context是该Host的默认Context
             docBase : 该Context的根目录是webapps/mycontext/
             -->

        <Context path="" docBase="mycontext" debug="0"/>
       

        <!-- 另外一个Context，路径名是/wsota -->

        <Context path="/wsota" docBase="wsotaProject" debug="0"/>
            
       
      </Host>
     
    </Engine>

  </Service>

</Server>

<!----------------------------------------------------------------------------------------------->

4 - Context的部署配置文件web.xml的说明
一个Context对应于一个Web App，每个Web App是由一个或者多个servlet组成的
当一个Web App被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类
它首先载入在＄CATALINA_HOME/conf/web.xml中部署的servlet类
然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类
web.xml文件有两部分：servlet类定义和servlet映射定义
每个被载入的servlet类都有一个名字，且被填入该Context的映射表(mapping table)中，和某种URL PATTERN对应
当该Context获得请求时，将查询mapping table，找到被请求的servlet，并执行以获得请求回应

　　分析一下所有的Context共享的web.xml文件，在其中定义的servlet被所有的Web App载入

<!----------------------------------------------------------------------------------------------->

<web-app>

  <!-- 概述：
       该文件是所有的WEB APP共用的部署配置文件，
       每当一个WEB APP被DEPLOY，该文件都将先被处理，然后才是WEB APP自己的/WEB-INF/web.xml
       -->

  <!--  +-------------------------+  -->
  <!--  |    servlet类定义部分    |  -->
  <!--  +-------------------------+  -->

  <!-- DefaultServlet
       当用户的HTTP请求无法匹配任何一个servlet的时候，该servlet被执行
       URL PATTERN MAPPING : /
       -->

    <servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.DefaultServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>true</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

  <!-- InvokerServlet
       处理一个WEB APP中的匿名servlet
       当一个servlet被编写并编译放入/WEB-INF/classes/中，却没有在/WEB-INF/web.xml中定义的时候
       该servlet被调用，把匿名servlet映射成/servlet/ClassName的形式
       URL PATTERN MAPPING : /servlet/*
       -->

    <servlet>
        <servlet-name>invoker</servlet-name>
        <servlet-class>
          org.apache.catalina.servlets.InvokerServlet
        </servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <load-on-startup>2</load-on-startup>
    </servlet>

  <!-- JspServlet
       当请求的是一个JSP页面的时候（*.jsp）该servlet被调用
       它是一个JSP编译器，将请求的JSP页面编译成为servlet再执行
       URL PATTERN MAPPING : *.jsp
       -->

    <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>logVerbosityLevel</param-name>
            <param-value>WARNING</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>

  <!--  +---------------------------+  -->
  <!--  |    servlet映射定义部分    |  -->
  <!--  +---------------------------+  -->

   
    <servlet-mapping>
        <servlet-name>default</servlet-name>
        <url-pattern>/</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>invoker</servlet-name>
        <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>jsp</servlet-name>
        <url-pattern>*.jsp</url-pattern>
    </servlet-mapping>

  <!--  +------------------------+  -->
  <!--  |    其它部分，略去先    |  -->
  <!--  +------------------------+  -->

    ... ... ... ...

</web-app>

<!----------------------------------------------------------------------------------------------->

5 - Tomcat Server处理一个http请求的过程
假设来自客户的请求为：
http://localhost:8080/wsota/wsota_index.jsp

1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得

2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应

3) Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host

4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）

5) localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context

6) Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）

7) path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet

8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类

9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法

10)Context把执行完了之后的HttpServletResponse对象返回给Host

11)Host把HttpServletResponse对象返回给Engine

12)Engine把HttpServletResponse对象返回给Connector

13)Connector把HttpServletResponse对象返回给客户browser

<html>
    <head>
        <meta http-equiv="refresh" content="5;url=<@s.url includeParams="none"/>"/>
    </head>
    <body>
        Please wait while we process your request...
        <p/>

        This page will reload automatically and display your request when it is completed.
    </body>
</html>

其中的includeParams参数取值为

none,不把参数参加到url参数中

all,是把get和post中的参数参加到url参数中

get,是只把get中的参数参加到url参数中

public BackgroundProcess(String threadName, final ActionInvocation invocation, int threadPriority) {
        this.invocation = invocation;
        this.action = invocation.getAction();
        try {
            final Thread t = new Thread(new Runnable() {
                public void run() {
                    try {
                        beforeInvocation();
                        result = invocation.invokeActionOnly();
                        afterInvocation();
                    } catch (Exception e) {
                        exception = e;
                    }

                    done = true;
                }
            });
            t.setName(threadName);
            t.setPriority(threadPriority);
            t.start();
        } catch (Exception e) {
            exception = e;
        }
    }

 if ((!executeAfterValidationPass || secondTime) && bp == null) {
                bp = getNewBackgroundProcess(name, actionInvocation, threadPriority);
                session.put(KEY + name, bp);//放入session
                performInitialDelay(bp); // first time let some time pass before showing wait page
                secondTime = false;
            }

            if ((!executeAfterValidationPass || !secondTime) && bp != null && !bp.isDone()) {//是否完毕
                actionInvocation.getStack().push(bp.getAction());//将后台action的相关信息push到statck，时候的页面可是使用        
        if (TokenHelper.getToken() != null) {
                    session.put(TokenHelper.getTokenName(), TokenHelper.getToken());
                }

                Map results = proxy.getConfig().getResults();
                if (!results.containsKey(WAIT)) {//如果没有配置wait，struts将为你inject一个
                    LOG.warn("ExecuteAndWait interceptor has detected that no result named 'wait' is available. " +
                            "Defaulting to a plain built-in wait page. It is highly recommend you " +
                            "provide an action-specific or global result named '" + WAIT +
                            "'.");
                    // no wait result? hmm -- let's try to do dynamically put it in for you!

                    //we used to add a fake "wait" result here, since the configuration is unmodifiable, that is no longer
                    //an option, see WW-3068
                    FreemarkerResult waitResult = new FreemarkerResult();
                    container.inject(waitResult);
                    waitResult.setLocation("/org/apache/struts2/interceptor/wait.ftl");
                    waitResult.execute(actionInvocation);

                    return Action.NONE;
                }

                return WAIT;
            } else if ((!executeAfterValidationPass || !secondTime) && bp != null && bp.isDone()) {//如果执行完毕return  bp.getResult();
                session.remove(KEY + name);
                actionInvocation.getStack().push(bp.getAction());

                // if an exception occured during action execution, throw it here
                if (bp.getException() != null) {
                    throw bp.getException();
                }

                return bp.getResult();
            } else {
                // this is the first instance of the interceptor and there is no existing action
                // already run in the background, so let's just let this pass through. We assume
                // the action invocation will be run in the background on the subsequent pass through
                // this interceptor
                return actionInvocation.invoke();
            }

豆瓣从今年开始也加入 Google Analytics 的统计阵营。让我们通过它加载的 Google Analytics 源码，简单分析一下它都是怎么应用的。

我们先从豆瓣的源码来看看它的Google Analytics统计代码

豆瓣 Google Analytics 代码

我们知道一般默认的 Google Analytics代码如下：

默认 Google Analytics 统计代码

两相对比，我们就会发现豆瓣加载 ga.js 的方式与默认的方式有些不太一样，由于豆瓣并没有采用 https 加密访问，所以撇弃了默认的ga.js加载方式。

默认的统计函数，pageTracker 也被豆瓣改成了 _ga ，这个只是名称定义上的区别，并没有什么实质的改变。豆瓣的主要应用是下面两个函数：

使用 _ga._addOrganic 识别非主流搜索引擎

再来看豆瓣比默认 Google Analytics 代码增加的部分，那就是多了数个 _ga._addOrganic ，这是 Google Analytics 添加自定义搜索引擎的代码。尽管 Google Analytics 对于主流的搜索引擎都能自动识别，但毕竟能识别的是国外的主流搜索引擎，在国内，像搜狐的 Sogou，QQ 的 soso，网易的有道等搜索引擎，都不能被 Google Analytics 正确识别，而被当作推荐来源。这时候我们就可以利用_addOrganic 参数来识别这些非主流搜索引擎，如豆瓣的做法。

使用 _addIgnoredOrganic 忽略关键字

除了添加自定义搜索引擎，豆瓣在最后还添加了如下这些代码:

_ga._addIgnoredOrganic("豆瓣");
_ga._addIgnoredOrganic("douban");
_ga._addIgnoredOrganic("豆瓣网");
_ga._addIgnoredOrganic("www.douban.com");

这些代码用来把引号中的关键词从搜索引擎的关键词报告中排除，而当成直接点击量来源。

为什么要这么做？因为一个知名的大网站，来自这些品牌词的搜索流量都非常大，常常是排在前几位的搜索关键词来源，而这通常是因为搜索引擎养成现在的人都懒得记网址，直接搜索品牌名来记住域名。这些品牌词对于网站的关键词来源分析并没有很直接的帮助，所以在来自品牌词的流量很大的情况下，可以直接把这些关键词识别成直接点击量来源。

关于自定义 Google Analytics 搜索引擎和排除特定关键词为直接点击量来源的语法，可以参考 Google Code 上关于这方面的详细介绍。

通过 _setVar 识别用户

当我们登录豆瓣后，再来分析豆瓣的源码，会发现多了一个ga._setVar(”xxxx”)的 Google Analytics 参数。

豆瓣使用 Google Analytics 的._setVar参数来跟踪登录用户行为

_setVar() 函数是 Google Analytics 的用户定义函数，主要用于对特定来源的用户行为进行分类，例如可以对登录浏览的用户设置一个数值，然后在 Google Analytics 后台的访问者/用户定义 中查看其浏览属性。

Google Analytics 访问者/用户定义报告

分析豆瓣的源码可以知道，豆瓣对每一个登录后的用户，都赋以一个专门的 id 值，这样可以在用户定义报告里，看到整体的登录用户访问行为，乃至每个登录用户的浏览行为。通过这样设定后，豆瓣便可以轻易获取高忠诚度访问用户的访问行为。关于_setVar()的更多说明，请参阅 Google Analytics的技术文档

如何根据访问者在我的网站上访问的页面或在表单上做出的响应对其进行分类？在 Google Analytics 官方的帮助文件，也给出了另外一个应用案例

值得注意的是，原来在设置 _setVar() 函数的时候，整个网站的跳出率会出现重大的偏差，不过在最近的google analytics官方博客，指出该bug已经修正，客户在进行这方面设置的时候，还是要注意对比前后数据是否有重大偏差。

通过 _trackPageview 区分不同类型的评论

豆瓣上的书评，影评和乐评可以说是豆瓣网站的核心价值所在。一般评论的URL格式如下：

豆瓣上单条评论的URL

当我们查看该页面的网页源代码时，会发现有趣的现象:

豆瓣单条评论页的 Google Analytics 代码

我们知道，一般 Google Analytics 的_trackPageview() 括弧中的参数是留空的， Google Analytics 会自动捕获网址的 URL 参数，如果在 _trackPageview()括弧中输入特定的数值，那么在 Google Analytics 的报表中，URL 将是我们指定的参数，而不再是我们在地址栏看到的 URL。

如上面的例子，我们在 Google Analytics 中看到的URL将是/book/review/1946018/，而不再是我们在浏览器地址栏看到的/review/1946018/

当所在频道是电影或者音乐时，_trackPageview() 中的参数将根据所在频道的属性，变为/movie/xxxxx 或者 /music/xxxxx的数值。

豆瓣通过对的参数进行重新指定，主要有以下的好处：

保证了用户和搜索引擎看到的 URL 比较简短，达到 URL 对用户友好和对搜索引擎友好的目的；而在 Google Analytics 报告中，通过 内容/内容细目/ 报告，又能了解到各个频道总的浏览情况。

在GA的内容细目报告中，将会多出 /book/ /music/ /movie/ 这样的文件夹来，总而获得各个频道的合计浏览数据。

而如果只是使用默认 _trackPageview()，你将只能得到所有评论页面的浏览数据，而无法得到细分的各个频道的浏览数据。

关于_trackPageview()的具体的使用方法可参照 Google Code 的说明

注意事项:使用 _trackPageview() 参数重新指定 URL 之后，网站覆盖图的数据将受到影响。可参阅 Google Analytics 的官方帮助文件

除了豆瓣使用 _trackPageview() 来对URL进行重写，大众点评网也采用了类似的做法（应该是比豆瓣更早采用。。。因为是我在点评网任职时候实验的做法;那时候豆瓣还没有使用 Google Analytis 统计代码，呵呵），有兴趣的同学可以自己去研究点评的 Google Analytis 代码。

文章来自：http://fairyfish.net/2009/06/30/google-analytics-in-douban/

----------------------------------------大众点评网的的代码，主页的
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-464026-1");
pageTracker._addOrganic("soso", "w");
pageTracker._addOrganic("sogou", "query");
pageTracker._addOrganic("yodao", "q");
pageTracker._addOrganic("bing", "q");
pageTracker._addOrganic("gougou", "search");
pageTracker._initData();
pageTracker._trackPageview("home/beijing_all");
</script>
     
   这个是子页面search/category/2/10/g328
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-464026-1");
pageTracker._addOrganic("soso", "w");
pageTracker._addOrganic("sogou", "query");
pageTracker._addOrganic("yodao", "q");
pageTracker._addOrganic("bing", "q");
pageTracker._addOrganic("gougou", "search");
pageTracker._initData();
pageTracker._trackPageview("dp_searchpv_card");
pageTracker._trackPageview("dp_searchpv_promo");
pageTracker._trackPageview("search/beijing_food_category/g328");
</script>
可以看出其中的pageTracker._trackPageview("。。。");是动态的也就是页面的，我们可以动态的赋值，这样就可以显示正确的地址了。

  大家如果有什么这方面的经验可以一同分享下。