为了克服这个缺点可以采用动态连接库。这个时候连接器仅仅是在可执行文件中打上标志，说明需要使用哪些动态连接库；当运行程序时，加载器根据这些标志把所需的动态连接库加载到内存。

另外在当前的编程环境中，一般都提供方法让程序在运行的时候把某个特定的动态连接库加载并运行，也可以将其卸载（例如Win32的LoadLibrary()&FreeLibrary()和Posix的dlopen()&dlclose()）。这个功能被广泛地用于在程序运行时刻更新某些功能模块或者是程序外观。

What is ClassLoader?

与普通程序不同的是，Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java class加载到JVM里头运行，负责加载Java class的这部分就叫做Class Loader。

JVM本身包含了一个ClassLoader称为Bootstrap ClassLoader，和JVM一样，Bootstrap ClassLoader是用本地代码实现的，它负责加载核心Java Class（即所有java.*开头的类）。另外JVM还会提供两个ClassLoader，它们都是用Java语言编写的，由Bootstrap ClassLoader加载；其中Extension ClassLoader负责加载扩展的Java class（例如所有javax.*开头的类和存放在JRE的ext目录下的类），Application ClassLoader负责加载应用程序自身的类。

When to load the class?

什么时候JVM会使用ClassLoader加载一个类呢？当你使用java去执行一个类，JVM使用Application ClassLoader加载这个类；然后如果类A引用了类B，不管是直接引用还是用Class.forName()引用，JVM就会找到加载类A的ClassLoader，并用这个ClassLoader来加载类B。

Why use your own ClassLoader?

似乎JVM自身的ClassLoader已经足够了，为什么我们还需要创建自己的ClassLoader呢？

因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，如果编写你自己的ClassLoader，你可以做到：
1）在执行非置信代码之前，自动验证数字签名
2）动态地创建符合用户特定需要的定制化构建类
3）从特定的场所取得java class，例如数据库中
4) 等等

事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息。

目前的应用服务器大都使用了ClassLoader技术，即使你不需要创建自己的ClassLoader，了解其原理也有助于更好地部署自己的应用。 

ClassLoader Tree & Delegation Model

当你决定创建你自己的ClassLoader时，需要继承java.lang.ClassLoader或者它的子类。在实例化每个ClassLoader对象时，需要指定一个父对象；如果没有指定的话，系统自动指定ClassLoader.getSystemClassLoader()为父对象。如下图：

在Java 1.2后，java class的加载采用所谓的委托模式（Delegation Modle），当调用一个ClassLoader.loadClass()加载一个类的时候，将遵循以下的步骤：
1）检查这个类是否已经被加载进来了？
2）如果还没有加载，调用父对象加载该类
3）如果父对象无法加载，调用本对象的findClass()取得这个类。

所以当创建自己的Class Loader时，只需要重载findClass()这个方法。

Unloading? Reloading?

当一个java class被加载到JVM之后，它有没有可能被卸载呢？我们知道Win32有FreeLibrary()函数，Posix有dlclose()函数可以被调用来卸载指定的动态连接库，但是Java并没有提供一个UnloadClass()的方法来卸载指定的类。

在Java中，java class的卸载仅仅是一种对系统的优化，有助于减少应用对内存的占用。既然是一种优化方法，那么就完全是JVM自行决定如何实现，对Java开发人员来说是完全透明的。

在什么时候一个java class/interface会被卸载呢？Sun公司的原话是这么说的："class or interface may be unloaded if and only if its class loader is unreachable. Classes loaded by the bootstrap loader may not be unloaded."

事实上我们关心的不是如何卸载类的，我们关心的是如何更新已经被加载了的类从而更新应用的功能。JSP则是一个非常典型的例子，如果一个JSP文件被更改了，应用服务器则需要把更改后的JSP重新编译，然后加载新生成的类来响应后继的请求。

其实一个已经加载的类是无法被更新的，如果你试图用同一个ClassLoader再次加载同一个类，就会得到异常（java.lang.LinkageError: duplicate class definition），我们只能够重新创建一个新的ClassLoader实例来再次加载新类。至于原来已经加载的类，开发人员不必去管它，因为它可能还有实例正在被使用，只要相关的实例都被内存回收了，那么JVM就会在适当的时候把不会再使用的类卸载。

相对应的还有一个org.apache.tomcat.util.net.NioEndpoint，这个和前面那个功能差不多，但是用了NIO包里的API，有一个最大的区别就是，接收线程接收一个socket之后，可能会将这个socket先放入缓存池，然后worker从池里面拿socket去处理，比前面那个类看起来功能和性能都会提升很多，不过代码行有2K多，相当复杂，设计不够精巧，有兴趣可以去研究下。

org.apache.tomcat.util.buf.MessageBytes：这是一个接近底层的字符串处理类，为什么说是接近底层，是因为socket接收进来的都是字节类型，而java用的是char或者String，这之间的转换涉及到编码问题和性能问题，所以凡是socket收进来的信息，全部都用这个类表示，只有当要输出字符串的时候，才会将里面的字节进行转换，实现一种延迟加载的懒模式，被Tomcat底层所使用的Request类，就是大量使用了这个类来存放数据。我们来小小窥视一下，Request类：

或许大家会觉得，构造出这么多的类，性能会高到哪里去，其实不是这样的，不停的构造和销毁对象的确会损耗相当的性能，但是一个对象被构造出来，可以重复利用，那就相当完美了，这个类就是如此的设计，其中有一个回收资源的方法，叫recycle()，这个方法可以清空里面的数组，清空里面的对象，而不会销毁自己本身，因为使用它的对象，只要调用recycle，以后又可以重复使用了。

MessageBytes其实内置了2个重要的类，org.apache.tomcat.util.buf.ByteChunk和org.apache.tomcat.util.buf.CharChunk，这2个类带我们回到了C时代，为什么这么说？因为它简直就是一个字符串处理类，一些眼熟的算法全部映入眼帘，比如字符转匹配算法，indexOf，startsWith，判断字符转是否相等，查找字符，等等，比之JDK提供的性能更好，功能更强大（这句话说过了，呵呵）

还有一个实用的值得学习的数据结构是，org.apache.tomcat.util.buf.Ascii，如果知道表驱动的朋友们，一定对这个类很熟悉了，判断大小写？判断是不是英文单词？判断是不是空白符？判断是不是数字，将字节类型转换为int、long类型，大小写转换，等等。这些都是大学计算机课程的课后练习题

http://www.csdn.net/Develop/read_article.asp?id=27225

我想，接下来我们应该去了解一下 tomcat 是如何处理jsp和servlet请求的。

1.  我们以一个具体的例子，来跟踪TOMCAT，看看它是如何把Request一层一层地递交给下一个容器，并最后交给Wrapper来处理的。

以http://localhost:8080/web/login.jsp为例子

（以下例子，都是以tomcat4 源码为参考）

这篇心得主要分为3个部分： 前期， 中期， 和末期。

 前期：讲解了在浏览器里面输入一个URL，是怎么被tomcat抓住的。

中期：讲解了被tomcat抓住后，又是怎么在各个容器里面穿梭， 最后到达最后的处理地点。

末期：讲解到达最后的处理地点后，又是怎么具体处理的。

2、 前期 Request的born.

    在这里我先简单讲一下request这个东西。

     我们先看着这个URL：http://localhost:8080/web/login.jsp 它是动用了8080端口来进行socket通讯的。

     我们知道, 通过

       InputStream in = socket.getInputStream() 和

       OutputStream out = socket.getOutputStream()

     就可以实现消息的来来往往了。

     但是如果把Stream给应用层看，显然操作起来不方便。

     所以，在tomcat 的Connector里面， socket被封装成了Request和Response这两个对象。

     我们可以简单地把Request看成管发到服务器来的数据，把Response看成想发出服务器的数据。

     但是这样又有其他问题了啊？ Request这个对象是把socket封装起来了， 但是他提供的又东西太多了。

     诸如Request.getAuthorization(), Request.getSocket()。 像Authorization这种东西开发人员拿来基本上用不太着，而像socket这种东西，暴露给开发人员又有潜在的危险。 而且啊， 在Servlet Specification里面标准的通信类是ServletRequest和HttpServletRequest，而非这个Request类。 So, So, So. Tomcat必须得捣持捣持Request才行。 最后tomcat选择了使用捣持模式（应该叫适配器模式）来解决这个问题。它把org.apache.catalina.Request 捣持成了 org.apache.coyote.tomcat4.CoyoteRequest。 而CoyoteRequest又实现了ServletRequest和HttpServletRequest 这两种接口。 这样就提供给开发人员需要且刚刚需要的方法了。

    ok, 让我们在 tomcat的顶层容器 - StandardEngin 的invoke()方法这里设置一个断点， 然后访问

    http://localhost:8080/web/login.jsp， 我们来看看在前期都会路过哪些地方：

       1. run(): 536, java.lang.Thread, Thread.java

       CurrentThread

      2. run():666, org.apache.tomcat.util.threads.ThreadPool$ControlRunnable, ThreadPool.java

               ThreadPool

       3. runIt():589, org.apache.tomcat.util.net.TcpWorkerThread, PoolTcpEndpoint.java

         ThreadWorker

4.        processConnection():  549

org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler, Http11Protocol.java

                  http protocol parser

      5. Process(): 781, org.apache.coyote.http11.Http11Processor, Http11Processor.java

          http request processor

       6. service(): 193, org.apache.coyote.tomcat4.CoyoteAdapter,CoyoteAdapter.java

         adapter

       7. invoke(): 995, org.apache.catalina.core.ContainerBase, ContainerBase.java

   StandardEngin

    1. 主线程

    2. 启动线程池.

    3. 调出线程池里面空闲的工作线程。

    4. 把8080端口传过来由httpd协议封装的数据，解析成Request和Response对象。

    5. 使用Http11Processor来处理request

    6. 在Http11Processor里面， 又会call CoyoteAdapter来进行适配处理，把Request适配成实现了ServletRequest和HttpServletRequest接口的CoyoteRequest.

7. 到了这里，前期的去毛拔皮工作就基本上搞定，可以交给StandardEngin 做核心的处理工作了。

3. 中期。 在各个容器间的穿梭。

    Request在各个容器里面的穿梭大致是这样一种方式：

    每个容器里面都有一个管道（pipline）， 专门用来传送Request用的。

    管道里面又有好几个阀门（valve）， 专门用来过滤Request用的。

    在管道的低部通常都会放上一个默认的阀们。 这个阀们至少会做一件事情，就是把Request交给子容器。

    让我们来想象一下：

     当一个Request进入一个容器后， 它就在管道里面流动，波罗~ 波罗~ 波罗~ 地穿过各个阀门。在流到最后一个阀门的时候，吧唧~ 那个该死的阀门就把它扔给了子容器。 然后又开始 波罗~ 波罗~ 波罗~ ... 吧唧~.... 波罗~ 波罗~ 波罗~ ....吧唧~....

    就是通过这种方式， Request 走完了所有的容器。（ 感觉有点像消化系统，最后一个地方有点像那里~ ）

    OK， 让我们具体看看都有些什么容器， 各个容器里面又都有些什么阀门，这些阀们都对我们的Request做了些什么吧：

3.1 StandardEngin 的pipeline里面放的是：StandardEnginValve

在这里，VALVE做了三件事：

1.   验证传递过来的request是不是httpservletRequest.

2    验证传递过来的 request 是否携带了host header信息.

3    选择相应的host去处理它。（一般我们都只有一个host:localhost，也就是127.0.0.1）。

到了这个地方，我们的request就已经完成了在Engin这个部分的历史使命，通向前途未卜的下一站： host了。

3.2 StandardHost 的pipline里面放的是： StandardHostValve

1.   验证传递过来的request是不是httpservletRequest.

2.   根据Request来确定哪个Context来处理。

Context其实就是webapp，比如http://localhost:8080/web/login.jsp

这里web就是Context罗！

3.   既然确定了是哪个Context了，那么就应该把那个Context的classloader付给当前线程了。

        Thread.currentThread().setContextClassLoader(context.getLoader().getClassLoader());

   这样request就只看得见指定的context下面的classes啊， jar啊这些，而看不见tomcat本身的类，什么Engin啊， Valve啊。不然还得了啊！

4. 既然request到了这里了，看来用户是准备访问web这个web app了，咋们得更新一下这个用户的session不是！ Ok , 就由manager更新一下用户的session信息

5. 交给具体的Context 容器去继续处理Request.

6. Context处理完毕了，把classloader还回来。

3.3 StandardContext 的pipline里面放的是： StandardContextValve

1.   验证传递过来的request是不是httpservletRequest.

2.   如果request意图不轨，想要访问/meta-inf, /web-inf这些目录下的东西，呵呵，没有用D!

3.   这个时候就会根据Request到底是Servlet，还是jsp，还是静态资源来决定到底用哪种Wrapper来处理这个Reqeust了。

4.   一旦决定了到底用哪种Wrapper，OK，交给那个Wrapper处理。

4. 末期。 不同的需求是怎么处理的.

StandardWrapper

之前对Wrapper没有做过讲解，其实它是这样一种东西。

我们在处理Request的时候，可以分成3种。

处理静态的： org.apache.catalina.servlets.DefaultServlet  

处理jsp的：org.apache.jasper.servlet.JspServlet

处理servlet的：org.apache.catalina.servlets.InvokerServlet

不同的request就用这3种不同的servlet去处理。

Wrapper就是对它们的一种简单的封装，有了Wrapper后，我们就可以轻松地拦截每次的Request。也可以容易地调用servlet的init()和destroy()方法， 便于管理嘛！

具体情况是这么滴：

   如果request是找jsp文件，StandardWrapper里面就会封装一个org.apache.jasper.servlet.JspServlet去处理它。

   如果request是找 静态资源 ，StandardWrapper里面就会封装一个org.apache.jasper.servlet.DefaultServlet 去处理它。

   如果request是找servlet ，StandardWrapper里面就会封装一个org.apache.jasper.servlet.InvokerServlet 去处理它。

StandardWrapper同样也是容器，既然是容器， 那么里面一定留了一个管道给request去穿，管道低部肯定也有一个阀门(注1)，用来做最后一道拦截工作.

在这最底部的阀门里，其实就主要做了两件事:

   一是启动过滤器，让request在N个过滤器里面筛一通，如果OK！ 那就PASS。 否则就跳到其他地方去了。

   二是servlet.service((HttpServletRequest) request,(HttpServletResponse) response); 这个方法.

     如果是 JspServlet， 那么先把jsp文件编译成servlet_xxx, 再invoke servlet_xxx的servie()方法。

     如果是 DefaultServlet， 就直接找到静态资源，取出内容， 发送出去。

     如果是 InvokerServlet， 就调用那个具体的servlet的service()方法。

   ok! 完毕。

注1: StandardWrapper 里面的阀门是最后一道关口了。 如果这个阀门欲意把request交给StandardWrapper 的子容器处理。 对不起， 在设计考虑的时候， Wrapper就被考虑成最末的一个容器， 压根儿就不会给Wrapper添加子容器的机会！ 如果硬是要调用addChild(), 立马抛出IllegalArgumentException！

参考：

     <http://jakarta.apache.org/tomcat/>
   <http://www.onjava.com/pub/a/onjava/2003/05/14/java_webserver.html>

Digester框架属于Jakarta Commons，它以规则和模式为基础处理XML文档。与SAX和DOM之类的标准API相比，Digester不涉及太多的细节问题，非常适合于对XML文档进行简单的处理。

在Java和XML开发中，一个常见的任务是把XML文档转换成对应的Java Bean对象的层次结构。人们经常用标准的SAX和DOM API来完成这个任务。虽然这两种API都很强大和灵活，但对于某些简单的任务来说，它们显得操作层次太低，也就是说，涉及了太多的细节问题。Jakarta Digester框架能够很好地满足这类场合的需要。

Jakarta的Digester框架从Struts框架发展而来，原先被用来处理struts-config.xml配置文件，但很快人们认识到它有着更广泛的用途，把它转入了Jakarta Commons项目。Jakarta Commons的目标是提供一个“可重用Java组件的仓库”。Digester最新的版本是1.3，于2002年8月13日发布。

Digester框架允许开发者指定一组动作，当解析器在XML文档中发现某些特定的简单模式时动作被执行。Digester框架带有10个预定义的规则（Rule），涵盖了unmarshalling XML（例如创建Bean或设置Bean属性）的大多数需求（ marshalling的原意是指“配制整齐，编组列车”，marshalling是在内存中为Java对象生成XML描述文档的过程，而unmarshalling是指把XML形式的描述转换到可用Java代码操作的对象的过程，我们称之为“反配制”），但必要时用户可以定义和实现自己的规则。

在本文的例子中，我们将反配制下面这个XML文档：

<?xml version="1.0"?> <catalog library="somewhere"> <book> <author>Author 1</author> <title>Title 1</title> </book> <book> <author>Author 2</author> <title>His One Book</title> </book> <magazine> <name>Mag Title 1</name> <article page="5"> <headline>Some Headline</headline> </article> <article page="9"> <headline>Another Headline</headline> </article> </magazine> <book> <author>Author 2</author> <title>His Other Book</title> </book> <magazine> <name>Mag Title 2</name> <article page="17"> <headline>Second Headline</headline> </article> </magazine> </catalog>

下面是Bean的代码。注意使用Digester框架时，Bean类必须定义成public。

import java.util.Vector; public class Catalog { private Vector books; private Vector magazines; public Catalog() { books = new Vector(); magazines = new Vector(); } public void addBook( Book rhs ) { books.addElement( rhs ); } public void addMagazine( Magazine rhs ) { magazines.addElement( rhs ); } public String toString() { String newline = System.getProperty( "line.separator" ); StringBuffer buf = new StringBuffer(); buf.append( "--- Books ---" ).append( newline ); for( int i=0; i<books.size(); i++ ){ buf.append( books.elementAt(i) ).append( newline ); } buf.append( "--- Magazines ---" ).append( newline ); for( int i=0; i<magazines.size(); i++ ){ buf.append( magazines.elementAt(i) ).append( newline ); } return buf.toString(); } } //=================================================== public class Book { private String author; private String title; public Book() {} public void setAuthor( String rhs ) { author = rhs; } public void setTitle( String rhs ) { title = rhs; } public String toString() { return "Book: Author='" + author + "' Title='" + title + "'"; } } //=================================================== import java.util.Vector; public class Magazine { private String name; private Vector articles; public Magazine() { articles = new Vector(); } public void setName( String rhs ) { name = rhs; } public void addArticle( Article a ) { articles.addElement( a ); } public String toString() { StringBuffer buf = new StringBuffer( "Magazine: Name='" + name + "' "); for( int i=0; i<articles.size(); i++ ){ buf.append( articles.elementAt(i).toString() ); } return buf.toString(); } } //=================================================== public class Article { private String headline; private String page; public Article() {} public void setHeadline( String rhs ) { headline = rhs; } public void setPage( String rhs ) { page = rhs; } public String toString() { return "Article: Headline='" + headline + "' on page='" + page + "' "; } }

1 2 下一页>>

Digester框架以模式（Pattern）和规则（Rule）为基础处理输入的XML。模式必须与XML元素匹配，包括其名字和在文档树内的位置。描述匹配模式的语法类似于XPath匹配模式，例如：catalog模式匹配顶层的<catalog>元素，catalog/book模式匹配直接嵌套在<catalog>元素内的<book>元素（但不匹配文档内其他位置的<book>元素）。

所有的模式都必须指定其完整名称——从根元素开始的完整路径。唯一的例外是包含通配符（“*”）的模式，例如*/name模式匹配XML文档内任何位置的<name>元素。但是根元素不必特别指出，因为所有的路径都是从根元素开始的绝对路径。

当Digester发现一个指定的模式，它就执行关联的任务。由此可见，Digester框架显然与SAX解析器有着密切的关系（实际上，Digester类实现了org.xml.sax.ContentHandler，并维护着解析栈）。所有在Digester中使用的规则必须扩展org.apache.commons.digester.Rule，后者本身提供了一些类似于SAX的ContentHandler回调函数的方法。例如，当遇到匹配元素的开始标记和结束标记时，begin()方法和end()方法将分别被调用。

一旦遇到匹配元素的内容，body()方法被调用；最后被调用的方法是finish()，这个方法在匹配元素的结束标记处理完毕之后被调用，用来执行可能需要的事后清理任务。然而，大多数时候我们不必关注这些方法，因为框架提供的标准规则很可能已经提供了所有必需的功能。

要反配制一个文档，首先创建一个org.apache.commons.digester.Digester类的实例，如果必要的话，进行一些配置操作，指定必需的模式和规则，最后向parse()方法传递一个XML文件的引用。下面的DigesterDriver示范了这一处理过程（必须在命令行上指定输入XML文档的名称）。

import org.apache.commons.digester.*; import java.io.*; import java.util.*; public class DigesterDriver { public static void main( String[] args ) { try { Digester digester = new Digester(); digester.setValidating( false ); digester.addObjectCreate( "catalog", Catalog.class ); digester.addObjectCreate( "catalog/book", Book.class ); digester.addBeanPropertySetter( "catalog/book/author", "author" ); digester.addBeanPropertySetter( "catalog/book/title", "title" ); digester.addSetNext( "catalog/book", "addBook" ); digester.addObjectCreate( "catalog/magazine", Magazine.class ); digester.addBeanPropertySetter( "catalog/magazine/name", "name" ); digester.addObjectCreate( "catalog/magazine/article", Article.class ); digester.addSetProperties( "catalog/magazine/article", "page", "page" ); digester.addBeanPropertySetter( "catalog/magazine/article/headline" ); digester.addSetNext( "catalog/magazine/article", "addArticle" ); digester.addSetNext( "catalog/magazine", "addMagazine" ); File input = new File( args[0] ); Catalog c = (Catalog)digester.parse( input ); System.out.println( c.toString() ); } catch( Exception exc ) { exc.printStackTrace(); } } }

在上面的代码中，我们首先创建了Digester类的一个实例digester，然后指定它不要用DTD验证XML文档的合法性——这是因为我们没有为XML文档定义DTD。接下来，我们指定了模式和关联的规则：ObjectCreateRule创建指定类的一个实例，并将它压入解析栈。SetPropertiesRule把Bean属性设置成当前XML元素的属性值——规则的第一个参数是XML属性的名称，第二个参数是Bean属性的名称。

SetPropertiesRule获取的是XML属性的值，而BeanPropertySetterRule获取的是位于当前元素内的原始字符数据值。使用BeanPropertySetterRule时不必指定要设置的Bean属性名字，默认是当前XML元素的名称。在上面的例子中，在匹配catalog/magazine/article/headline模式的规则定义中使用的就是默认值。最后，SetNextRule弹出解析栈顶部的对象，并把该对象传递给它下面对象的指定名称的方法——通常用来把一个配置完毕的Bean插入父对象。

注意，我们可以为同一个模式注册多个规则。如果注册了多个规则，则这些规则按照它们被加入到Digester的次序执行，例如，如果要处理catalog/magazine/article的

元素，我们首先创建合适的article Bean，然后设置page属性，最后弹出完成后的article Bean，并把它插入magazine。

调用任意方法

我们不仅可以设置Bean的属性，而且还可以调用堆栈内对象的任意方法。这通过CallMethodRule完成，我们只需指定方法名字，如有必要，再说明调用的参数类型和数量。CallParamRule用来定义传递给被调用函数的参数值，参数值可以从当前XML元素的命名的属性获取，也可以从当前元素包含的原始字符数据获取。例如，在前面实现DigesterDriver的例子中，我们可以不用BeanPropertySetterRule，而是通过显式调用属性的set方法达到同样的目的：

digester.addCallMethod( "catalog/book/author", "setAuthor", 1 ); digester.addCallParam( "catalog/book/author", 0 );

上面的第一行代码给出了要调用的方法（即setAuthor()），以及该调用需要的参数数量（即1）。第二行代码的意思是从元素包含的字符数据获取函数参数的值，把它作为参数数组的第一个传入（即索引是0的数组元素）。如果我们指定了XML元素属性的名称（例如digester.addCallParam( "catalog/book/author", 0, "author" );），则参数值将从当前元素的相应属性值获取。

这里必须注意的是，“digester.addCallMethod( "pattern", "methodName", 0 );”这个语句不是指定了一个不带参数的方法调用，而是指定了带有一个参数的方法调用，它的值就是当前XML元素的字符数据！这样，我们又有了另一种替代BeanPropertySetterRule的办法：

digester.addCallMethod( "catalog/book/author", "setAuthor", 0 );

如果要调用一个确实没有参数的方法，必须采用如下形式：digester.addCallMethod( "pattern", "methodName" );。

标准规则概要

下面简要说明所有标准规则。

创建

ObjectCreateRule：利用指定类的默认构造函数，创建该类的一个对象，并把对象压入栈。当元素处理结束时，对象被弹出。被实例化的类可通过class对象或类的全称给出。

FactoryCreateRule：利用指定的工厂类创建一个对象，把对象压入栈。对于没有提供默认构造函数的类，这一规则很有用。用于该规则的工厂类必须实现org.apache.commons.digester.ObjectCreationFactory接口。

设置属性

SetPropertiesRule：利用指定名称的XML元素属性值，设置顶层Bean的一个或者多个指定名称的属性。XML元素的属性名称和Bean的属性名称以String[]数组形式传入该规则（通常用来处理

之类的结构）。

BeanPropertySetterRule：把顶层Bean的指定名称的属性设置成当前XML元素包含的字符数据。（通常用来处理<page>10</page>之类的结构）。

SetPropertyRule：设置顶层Bean的一个属性。无论是Bean属性的名称，还是赋予该属性的值，都在当前XML元素中以属性的形式指定，例如：<article key="page" value="10" />。

管理父/子关系

SetNextRule：弹出栈顶的对象，把它传递给紧接其下的另一个对象的指定名称的方法。通常用来把一个已经初始化的Bean插入到父对象。

SetTopRule：把栈里面上数第二的对象传递给顶层的对象。当子对象提供了一个setParenet方法时，这一规则很有用。

SetRootRule：调用栈底对象的一个方法，并把栈顶的对象作为参数传入。

调用任意方法

CallMethodRule：调用顶层Bean的指定名称的方法。被调用的方法可以有任意多个参数，参数的值通过后继的CallParamRule给出。

CallParamRule：表示方法调用的参数。参数的值或者取自指定名称的XML元素的属性，或者是当前元素包含的原始字符数据。这个规则要求用一个整数指定它在参数列表中的位置。

通过XML指定规则

在前面的内容中，我们用程序代码的方式指定模式和规则，这些模式和规则都是在编译的时候就已经确定，虽然从概念上来讲比较简单，但却不能说尽善尽美：Digester框架的总体目标是在运行时识别和处理各种数据结构，但如果我们用编程的方法指定模式和规则，则所有行为在编译时已经固定！如果Java源程序中包含了大量固定的字符串，通常意味着程序在执行某些配置操作，这部分操作可以被（或许是应该被）延迟到运行时进行。

org.apache.commons.digester.xmlrules包解决了这个问题。这个包提供了一个DigesterLoader类，它能够从XML文档读取模式/规则对，返回配置好的Digester对象。用来配置Digester对象的XML文档必须遵从digester-rules.dtd，这个DTD是xmlrules包的一部分。

下面就是本文例子的配置文件rules.xml。有几点必须说明。

首先，模式可以用两种方式指定：或者使用<pattern>元素，或者通过代表规则的XML元素的属性。这两种办法可以混合使用，且<pattern>元素是可以嵌套的。其次，<alias>元素和<set-properties-rule>一起使用，用来把XML属性映射到Bean属性。最后，就当前发行的Digester软件包而言，我们不能在配置文件中指定BeanPropertySetterRule，正如前面所介绍的，我们用CallMethodRule来达到同样的目标。

<?xml version="1.0"?> <digester-rules> <object-create-rule pattern="catalog" classname="Catalog" /> <set-properties-rule pattern="catalog" > <alias attr-name="library" prop-name="library" /> </set-properties-rule> <pattern value="catalog/book"> <object-create-rule classname="Book" /> <call-method-rule pattern="author" methodname="setAuthor" paramcount="0" /> <call-method-rule pattern="title" methodname="setTitle" paramcount="0" /> <set-next-rule methodname="addBook" /> </pattern> <pattern value="catalog/magazine"> <object-create-rule classname="Magazine" /> <call-method-rule pattern="name" methodname="setName" paramcount="0" /> <pattern value="article"> <object-create-rule classname="Article" /> <set-properties-rule> <alias attr-name="page" prop-name="page" /> </set-properties-rule> <call-method-rule pattern="headline" methodname="setHeadline" paramcount="0" /> <set-next-rule methodname="addArticle" /> </pattern> <set-next-rule methodname="addMagazine" /> </pattern> </digester-rules>

现在，所有实际的操作都转移到了Digester和DigesterLoader类，XmlRulesDriver类就变得相当简单。运行下面的XmlRulesDriver时，在第一个命令行参数中指定目录文档的名字，在第二个参数中指定rules.xml（注意，DigesterLoader不是从File或者org.xml.sax.InputSource读取rules.xml文件，而是要求指定一个URL，因此，下面代码中File引用被转换成了等价的URL）。

import org.apache.commons.digester.*; import org.apache.commons.digester.xmlrules.*; import java.io.*; import java.util.*; public class XmlRulesDriver { public static void main( String[] args ) { try { File input = new File( args[0] ); File rules = new File( args[1] ); Digester digester = DigesterLoader.createDigester( rules.toURL() ); Catalog catalog = (Catalog)digester.parse( input ); System.out.println( catalog.toString() ); } catch( Exception exc ) { exc.printStackTrace(); } } }

结束语：本文对Jakarta Commons Digester的介绍就到这里结束。当然，还有许多内容这里尚未涉及。其中一个在这里忽略的主题是XML名称空间：Digester允许把规则定义成只能对某一个名称空间内定义的元素起作用。

另外，我们简单地提及了通过扩展Rule类开发定制规则的问题。按照习惯，Digester类提供了push()、peek()和pop()方法，使得开发者能够自由地直接操作解析栈。

参考：

Jakarta Commons Digester Homepage

Jakarta Struts Homepage

林光炎 2009-08-26 20:27 发表评论

]]>http://www.blogjava.net/lingy/archive/2009/08/25/292559.html林光炎林光炎Tue, 25 Aug 2009 12:36:00 GMThttp://www.blogjava.net/lingy/archive/2009/08/25/292559.html相关文章:  
正确理解ThreadLocal
ThreadLocal与synchronized

推荐圈子: Pipboy
更多相关推荐
昨天上Java版块逛了一圈，一个2万5千人浏览的帖子引起了偶滴注意 ThreadLocal与synchronized ，9页以上的回复，足见大家对这个问题的兴趣。

老实说，从看到这个帖子的题目开始，就觉得帖子的作者估计是在概念上有所混淆了,于是乎想写个咚咚，同大家分享一下自己的心得。

帖子上，讨论的人很多，高手不乏，各抒己见，但不知新手们看明白没有，因此，这里偶以最简洁列表方式来说一说相关问题。

1．区别ThreadLocal 与 synchronized

ThreadLocal是一个线程隔离(或者说是线程安全)的变量存储的管理实体（注意：不是存储用的），它以Java类方式表现；
synchronized是Java的一个保留字，只是一个代码标识符，它依靠JVM的锁机制来实现临界区的函数、变量在CPU运行访问中的原子性。
两者的性质、表现及设计初衷不同，因此没有可比较性。

2.理解ThreadLocal中提到的变量副本
事实上，我们向ThreadLocal中set的变量不是由ThreadLocal来存储的，而是Thread线程对象自身保存。当用户调用ThreadLocal对象的set(Object o)时，该方法则通过Thread.currentThread()获取当前线程，将变量存入Thread中的一个Map内，而Map的Key就是当前的ThreadLocal实例。请看源码，这是最主要的两个函数，能看出ThreadLocal与Thread的调用关系：

Java代码
public void set(T value) {   
        Thread t = Thread.currentThread();   
        ThreadLocalMap map = getMap(t);   
        if (map != null)   
            map.set(this, value);   
        else  
            createMap(t, value);   
}   
  
ThreadLocalMap getMap(Thread t) {   
        return t.threadLocals;   
}  
public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
}

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
}

（有兴趣的朋友可以阅读Java的ThreadLocal源码）因此，我们可以知道，所谓的变量副本，即是对Object Reference（对象引用）的拷贝。

3.理解Thread和 ThreadLocal对变量的引用关系
实际上Thread和ThreadLocal对变量引用关系就像是坐标系中的X轴和Y轴，是从两个维度上来组织对变量的引用的。

首先说Thread。 我们知道一个ThreadOne的执行会贯穿多个方法MethodA、MethodB、MethodC这些方法可能分布于不同的类实例。假设，这些方法分别使用了ThreadLocalA、ThreadLocalB、ThreadLocalC来保存线程本地变量，那么这些变量都存于ThreadOne的Map中，并使用各自的ThreadLocal实例作为key。 因此，可以认为，借助ThreanLocal的set方法，在X轴上，Thread横向关联同一线程上下文中来自多个Method的变量引用副本。

 

接着说ThreadLocal。 一个MethodA中的X变量将被多个线程ThreadOne、ThreadTwo、ThreadThree所访问。假设MethodA使用ThreadLocal存储X，通过set方法，以ThreadLocal作为key值，将不同线程来访时的不同的变量值引用保存于ThreadOne、ThreadTwo、ThreadThree的各自线程上下文中，确保每个线程有自己的一个变量值。因此，可以认为，ThreadLocal是以Method为Y轴，纵向关联了处于同一方法中的不同线程上的变量。

 

希望能对大家有所帮助，这样可以少走很多弯路哦。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yangairong1984/archive/2008/04/15/2294572.aspx

林光炎 2009-08-25 20:36 发表评论

]]>http://www.blogjava.net/lingy/archive/2009/06/22/283575.html林光炎林光炎Mon, 22 Jun 2009 07:06:00 GMThttp://www.blogjava.net/lingy/archive/2009/06/22/283575.html 　　下载地址为http://Java.chinaitlab.com/tools/45970.Html 。将cactus的lib目录下的cactus-ant-1.7.1.jar复制到ant的lib目录。
　　二、配置cactus
　　cactus的配置很简单，新建一个cactus.properties文件，并把它放在ant脚本中的cactus任务的classpath下，文件中包括如下内容
　　cactus.sysproperties=cactus.contextURL
　　#cactus-sample-servlet-cactified就是你的测试应用所在路径，8080是端口号
　　cactus.contextURL = http://localhost:8080/cactus-sample-servlet-cactified
　　cactus.servletReDirectorName = ServletRedirector
　　cactus.jspRedirectorName = JspRedirector
　　cactus.filterRedirectorName = FilterRedirector
　　具体的做法结合ant脚本再进一步解释。
　　三、运行ant脚本
　　 ant脚本主要执行以下任务
　　1、设定classpath
　　<path id="project.classpath">
　　 <fileset dir="${lib.dir}">
　　 <include name="*.jar"/>
　　 </fileset>
　　 <!-- cactus.properties文件就需要放在lib.dir所对应的路径中 -->
　　 <pathelement location="${lib.dir}"/>
　　 <pathelement location="${tomcat.home}/common/lib/jsp-api.jar"/>
　　 <pathelement location="${tomcat.home}/common/lib/servlet-api.jar"/>
　　 </path>
　　2、定义相关任务
　　<taskdef resource="cactus.tasks" classpathref="project.classpath"/>
　　 <taskdef name="runservertests" classname="org.apache.cactus.integration.ant.RunServerTestsTask">
　　 <classpath>
　　 <path refid="project.classpath"/>
　　 </classpath>
　　 </taskdef>
　　3、编译应用的类文件和测试的类文件
　　4、打包整个应用为war文件
　　需要注重的是，不仅要打包应用类，测试类也要打包
　　<target name="war" depends="compile.java"
　　 description="Generate the runtime war">
　　 <war warfile="${target.dir}/${project.name}.war"
　　 webXML="${src.webapp.dir}/WEB-INF/web.xml">
　　 <fileset dir="${src.webapp.dir}">
　　 <exclude name="cactus-report.xsl"/>
　　 <exclude name="WEB-INF/cactus-web.xml"/>
　　 <exclude name="WEB-INF/web.xml"/>
　　 </fileset>
　　 <classes dir="${target.classes.java.dir}"/>
　　 <!-- 别忘了打包测试类 -->
　　 <classes dir="${target.classes.test.dir}"/>
　　 <!-- 别忘了打包各种相关的jar文件 -->
　　 < lib dir="project.classpath"/>
　　 </war>
　　 </target>
　　5、在应用的web.xml文件中添加测试所需的各种映射
　　cactus提供了两个task来完成这个工作，CactifyWar和WebXmlMerge。
　　CactifyWar的功能是自动在已经打包的应用的web.xml文件中添加所需的映射。WebXmlMerge是提供合并两个web.xml文件的功能。
　　<target name="test.prepare"
　　 depends="war, compile.cactus, test.prepare.logging">
　　 <!-- Cactify the web-app archive -->
　　 <cactifywar srcfile="${target.dir}/${project.name}.war"
　　 destfile="${tomcat.home}/webapps/${project.name}-cactified.war"
　　 >
　　 <classes dir="${target.classes.java.dir}"/>
　　 <classes dir="${target.classes.test.dir}"/>
　　 <lib dir="project.classpath"/>
　　 </cactifywar>
　　</target>
　　6、运行测试
　　cactus提供了cactus和RunServerTests两个task来运行测试。
　　"cactus" task是通过复制容器服务器的最小文件并运行来运行测试，因此需要制定容器服务器的类型，启动速度稍快点，另外配置比较方便，但是无法测试象tomcat连接池等资源。另外对tomcat5.5的支持也不好。
　　"RunServerTests"是通过直接启动容器服务起来运行测试，因此速度稍慢，且配置较麻烦，但能测试各种资源。
　　<target name="test" depends="test.prepare"
　　 description="Run tests on Tomcat ">
　　 <!-- Start the servlet engine, wait for it to be started, run the
　　 unit tests, stop the servlet engine, wait for it to be stopped.
　　 The servlet engine is stopped if the tests fail for any reason -->
　　 <!-- 8080是服务器的端口号，${project.name}-cactified是项目的路径，和上一步的cactifywar 的destfile相对应 -->
　　 <runservertests
　　 testURL="http://localhost:8080/${project.name}-cactified/ServletRedirector?Cactus_Service=RUN_TEST"
　　 startTarget="_StartTomcat"
　　 stopTarget="_StopTomcat"
　　 testTarget="_Test"/>
　　 </target>
　　<!-- _Test就是一个普通的junit任务 -->
　　 <target name="_Test">
　　 <junit printsummary="yes" fork="yes">
　　 <classpath>
　　 <path refid="project.classpath"/>
　　 <pathelement location="${target.classes.java.dir}"/>
　　 <pathelement location="${target.classes.test.dir}"/>
　　 </classpath>
　　 <formatter type="brief" usefile="false"/>
　　 <formatter type="xml"/>
　　 <batchtest>
　　 <fileset dir="${src.test.dir}">
　　 <!-- Due to some Cactus synchronization bug, the 'unit' tests need
　　 to run before the 'sample' tests -->
　　 <include name="**/Test*.java"/>
　　 <exclude name="**/Test*All.java"/>
　　 </fileset>
　　 </batchtest>
　　 </junit>
　　 </target>
　　文章来源: baike.duba.net

林光炎 2009-06-22 15:06 发表评论

]]>http://www.blogjava.net/lingy/archive/2009/06/22/283551.html林光炎林光炎Mon, 22 Jun 2009 05:39:00 GMThttp://www.blogjava.net/lingy/archive/2009/06/22/283551.html 给servlet写单元测试的总结收藏
servlet的测试一般来说需要容器的支持，不是像通常的java类的junit测试一样简单，
 
下面通过对HelloWorld代码的测试阐述了几种servlet测试方法。
 
被测试的HelloWorld类的代码如下：
 
/**
 * 被测试的servlet
 */

import java.io.IOException;
 
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.cactus.WebRequest;
import org.apache.cactus.server.HttpServletRequestWrapper;
 
public class HelloWorld extends HttpServlet{
 
 public void saveToSession(HttpServletRequest request) {

         request.getSession().setAttribute("testAttribute",request.getParameter("testparam"));

 }
 
 public void doGet(HttpServletRequest request,HttpServletResponse response) throws IOException{

         String username=request.getParameter("username");

         response.getWriter().write(username+":Hello World!");
       
 }
 
 public boolean authenticate(){
        
        return true;
 
 }

}
 
以HelloWorld为例，我总结了Servlet的多种测试方法如下：
 
一.使用HttpUnit测试
 
import com.meterware.httpunit.GetMethodWebRequest;
import com.meterware.httpunit.WebRequest;
import com.meterware.httpunit.WebResponse;
import com.meterware.servletunit.InvocationContext;
import com.meterware.servletunit.ServletRunner;
import com.meterware.servletunit.ServletUnitClient;
import junit.framework.Assert;
import junit.framework.TestCase;
 
public class HttpUnitTestHelloWorld extends TestCase {
 
 protected void setUp() throws Exception {
  super.setUp();
 }
 
 protected void tearDown() throws Exception {
  super.tearDown();
 }
 
 public void testHelloWorld() {
 
  try {

   // 创建Servlet的运行环境

   ServletRunner sr = new ServletRunner();

   // 向环境中注册Servlet

   sr.registerServlet("HelloWorld", HelloWorld.class.getName());
 
   // 创建访问Servlet的客户端

   ServletUnitClient sc = sr.newClient();

   // 发送请求

   WebRequest request = new GetMethodWebRequest("http://localhost/HelloWorld");
   request.setParameter("username", "testuser");

   InvocationContext ic = sc.newInvocation(request);

   HelloWorld is = (HelloWorld) ic.getServlet();
 
   // 测试servlet的某个方法

   Assert.assertTrue(is.authenticate());

   // 获得模拟服务器的信息

   WebResponse response = sc.getResponse(request);

   // 断言

   Assert.assertTrue(response.getText().equals("testuser:Hello World!"));

  } catch (Exception e) {

   e.printStackTrace();

  }

 }
 
}
 
上述例子其实是junit的一个测试例子，在其中使用了httpunit模拟的servlet环境,使用上述方法测试
 
servlet可以脱离容器，容易把该测试写入ant或maven脚本，让测试进行。
 
httpunit网址：http://httpunit.sourceforge.net/
 
使用该种方法测试的弱点就是：如果要使用request(response)的setCharercterEncoding方法时，测试会出现一些问题,
 
而且httpunit在测试servlet行为时，采用的是完全模拟浏览器，有时测试比较难写。
 
二 使用cactus测试
 
/**
 * cactus测试servlet的例子
 * 必须要有tomcat的支持
 *
 */
 
import junit.framework.Test;
import junit.framework.TestSuite;
import org.apache.cactus.ServletTestCase;
import org.apache.cactus.WebRequest;
import org.apache.cactus.WebResponse;
public class CactusHelloWorld extends ServletTestCase{
 
     HelloWorld servlet;
     public CactusHelloWorld(String theName) {
         super(theName);
     }
 
     protected void setUp() throws Exception {
         super.setUp();
         servlet = new HelloWorld();
     }
 
     protected void tearDown() throws Exception {
         super.tearDown();
     }
 
     /**
      * 测试方法测试参数在此设置
      *
      * @param webrequest
      */
 
     public void beginSaveToSessionOK(WebRequest request) {
         request.addParameter("testparam", "it works!");
     }
    
     /**
      * 测试方法测试参数在此设置
      *
      * @param webrequest
      */
 
     public void beginDoGet(WebRequest request) {
         request.addParameter("username", "testuser");
     }
 
     /**
      * 调用servlet的测试方法
      * 
      */

     public void testSaveToSessionOK() {
         servlet.saveToSession(request);
         assertEquals("it works!", session.getAttribute("testAttribute"));
     }
 
     public void testDoGet() {
         try {
             servlet.doGet(request, response);
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
 
     /**
      * 此方法可以判断测试方法的输出，会传递测试方法的reponse给end***,并且格式化为cactus
      * 的WebResponse或者可以跟httpunit集成，格式化为httpunit的response
      *
      * @param response
      */

     public void endDoGet(WebResponse response) {
         String content;        
         content = response.getText();
         assertEquals("testuser:Hello World!", content);
     }
}
 
cactus具备丰富灵活的测试功能，如要测试doGet方法，分为beginDoGet(模拟测试参数设置)、DoGet(执行测试)、endDoGet(状态结果验证)
 
相比httpunit来说，写测试更为容易，测试servlet更为专业,流程更为清晰，但是cactus需要容器支持，使得测试不可以自动进行，但是
 
如果使用一个嵌入式的容器，测试就可以自动了。
 
cactus是一个servlet和jsp的测试框架:http://jakarta.apache.org/cactus/getting_started.html
 
三 使用Jetty作为嵌入式容器测试servlet.
 
/**
 * 一个关于嵌入式jetty测试的例子，jetty作为stubs的一个例子
 *
 */
package com.easyjf.testexample;
 
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.bio.SocketConnector;
import org.mortbay.jetty.servlet.ServletHandler;
 
import com.meterware.httpunit.WebClient;
import com.meterware.httpunit.WebConversation;
import com.meterware.httpunit.WebResponse;
 
import junit.framework.Assert;
import junit.framework.TestCase;
 
public class JettySampleTest extends TestCase {
 
 Server server;
 protected void setUp() throws Exception {
      //通过代码设置并启动一个服务器，该服务器是servlet的测试容器
      super.setUp();
      server = new Server();
      Connector connector=new SocketConnector();
      connector.setPort(80);
      server.setConnectors(new Connector[]{connector});
      ServletHandler handler=new ServletHandler();
      server.setHandler(handler);
      handler.addServletWithMapping("HelloWorld", "/");
      server.start();
 }
 
 protected void tearDown() throws Exception {
  super.tearDown();
  server.stop();
 }
 
 public void testHellWorld() {
  try {
   WebConversation wc = new WebConversation();
   WebResponse web = wc.getResponse("http://127.0.0.1/HelloWorld");
   String result=web.getText();
   Assert.assertEquals(result,"it works!");
  } catch (Exception e) {
   e.printStackTrace();
  }
 }
}
 
可以发现，jetty可以充当一个servlet的容器，方便的是,jetty支持嵌入式服务，即可以通过代码来启动，
 
所以要写自动测试的例子很方便，可以结合httpunit或者cactus进行servlet测试。
 
jetty主页：http://docs.codehaus.org/display/JETTY/Embedding+Jetty

四 使用mock对象，此处使用easymock
 
import java.io.PrintWriter;
import java.io.Writer;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
import junit.framework.Assert;
import junit.framework.TestCase;
import static org.easymock.EasyMock.*;
public class MockTestServlet extends TestCase {
 
    public void testService() throws Exception {

        System.out.println("service");

        HttpServletRequest request = createMock(HttpServletRequest.class);

        HttpServletResponse response = createMock(HttpServletResponse.class);

        //Creating the ServletConfig mock here

        ServletConfig servletConfig = createMock(ServletConfig.class);

        //Creating the ServletContext mock here

        ServletContext servletContext = createMock(ServletContext.class);
       
        //Create the target object 
     
        HelloWorld4 instance = new HelloWorld();

        //初始化servlet,一般由容器承担，一般调用servletConfig作为参数初始化，此处模拟容器行为

        instance.init(servletConfig);
 
        //在某些方法被调用时设置期望的返回值，如下这样就不会去实际调用servletConfig的getServletContext方法，而是直接返回
 
        //servletContext,由于servletConfig是mock出来的，所以可以完全控制。

        expect(servletConfig.getServletContext()).andReturn(servletContext).anyTimes();

        expect(request.getParameter("username")).andReturn("testuser");

        PrintWriter pw=new PrintWriter(System.out,true);

        expect(response.getWriter()).andReturn(pw).anyTimes();
       
        //以上均是录制，下面为重放，该种机制为easymock测试机制，要理解请看easymock测试的一些资料
        replay(request);
        replay(response);
        replay(servletConfig);
        replay(servletContext);
 
        instance.doGet(request, response);

        pw.flush();
       
 
        //验证结果是否预期，如果预期，则会在pw上写出testuser.
        verify(request);
        verify(response);
        verify(servletConfig);
        verify(servletContext);
   }
}
 
mock测试注重行为，mock对象其实都是模拟的对象，方法一般直接给出一个返回值，没有具体的对象逻辑，mock对象
 
是用来帮助测试要测试的类的。比如要测试servlet的内部行为，又不想要容器等环境，就可以采用mock测试。
 
easymock是mock测试的一个框架：http://www.easymock.org/
 
发表于 @ 2007年02月10日 22:13:00|评论(2)

新一篇: 设计模式之创建模式 | 旧一篇: 服务定位器模式(service locator)wldandanpig 发表于2007年5月24日 10:09:40  IP:举报
请问楼主
public String saveInfo()
{
String reqInfo = request.getParameter("reqInfo");
String sessInfo = (String)request.getSession().getAttribute("sessInfo");

request.setAttribute("reqInfo" , "response:"+reqInfo);
request.getSession().setAttribute("sessInfo", "response:"+reqInfo);

return "SUCCESS";
}
这个方法怎么测试啊cz_hyf 发表于2007年5月24日 17:20:23  IP:举报
如果用httpunit的话

public void testHelloWorld() {

try {

// 创建Servlet的运行环境

ServletRunner sr = new ServletRunner();

// 向环境中注册Servlet

sr.registerServlet("HelloWorld", HelloWorld.class.getName());

// 创建访问Servlet的客户端

ServletUnitClient sc = sr.newClient();

// 发送请求

WebRequest request = new GetMethodWebRequest("http://localhost/HelloWorld");
request.setParameter("reqInfo", "......");

InvocationContext ic = sc.newInvocation(request);

HelloWorld is = (HelloWorld) ic.getServlet();

// 测试servlet的某个方法

Assert.assertEquals(is.saveInfo,"SUCCESS");

} catch (Exception e) {

e.printStackTrace();

}

}

如果还不放心，不妨把request和request.session中的值取出来看看是否是你放进去的

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cz_hyf/archive/2007/02/10/1507211.aspx

林光炎 2009-06-22 13:39 发表评论

]]>http://www.blogjava.net/lingy/archive/2009/06/04/279972.html林光炎林光炎Thu, 04 Jun 2009 02:59:00 GMThttp://www.blogjava.net/lingy/archive/2009/06/04/279972.htmlJSP的内建对象不需要由JSP编写人员实例化,它们均由容器管理和实现,在所有的JSP页面中都能使用.只在Scriptlet或者表达式中使用.它们是:

１．request对象:

           代表请求对象,被包装成HttpServletRequest接口,通过getParameter方法得到request参数,通过 GET,POST,HEAD等方法得到request的类型.通过Cookies,Referer等可以得到Http头.来自客户端的请求经 Servlet容器处理后,由request对象进行封装,作为jspService()方法的一个参数由容器传递给JSP页面.主要方法有:request.getAttribute("..");request.getParameter("xxx");request.getParameterValues("xxx");request.getHeader("xxx") 获取HTTP协议定义的文件头信息.request.getRequestURI()获取发出请求字符串的客户端地址.request.getRemoteHost()客户端名,request.getRemoteAddr()客户端IP地址.request.getServerName()服务器名字.request.getServletPath();客户端所请求的脚本文件的文件路径.request.getServerPort()获取服务器的端口号.request.setAttribute("xxx","");等.

２．response

           响应请求对象,被包装成HttpServletResponse接口,与requst对象一样,是缓冲输出流,可以设置Http状态码和response 响应头.主要的方法有:response.addCookie(Cookie cookie);response.encodeURL();response.getOutputStream();response.sendRedirect("xxx") 把响应发到另一位置进行处理.

３．pageContext

          被封装成javax.servlet.jsp.pageContext接口,它为JSP页面包装页面的上下文.由容器创建和初始化,管理对属于JSP中特殊可见部分中已命名对象的访问.可用getServletContext()返回Servlet Context对象(这个Servlet Context对所有的页面都是共享的.),forward("xxx")把页面重定向到另一页面或者Servlet组件上.

 ４．session对象

           用来保存每个用户信息,以便跟踪每个用户的操作状态.其中session信息保存在容器中,session的ID保存在客户机的Cookiek .(一般情况中,用户每次登录系统时容器会给此用户分配一个唯一的标识session id,用于区别其它用户,当用户退出系统时,这个标识就会自动消失.其接口为HttpSession.主要的方法有:session.getId();getLastAccessedTime();setAttribute();

５．application

         与服务器启动后创建.直到服务器关闭而停止,为多个应用程序保存信息.

６．out对象:

            被封装成javax.servlet.jsp.JspWriter接口,它表示为客户打开的输出流,PrintWriter使用它向客户端发送输出流.即简单说向客户端输出数据.方法:out.print(....),out.newLine();out.flush();out.close();等,并可获取输出缓冲区的相关信息.如果要在页面中真正输出一个空行,需要用out.println("<br>")来实现.

７．config

         被封装为javax.servlet.ServletConfig接口,它表示了Servlet的配置.当一个Servlet初始化时,容器把某些信息通过 此对象传递给这个Servlet.,常用的方法有:getServletContext();

８．page

         是java.lang.Object类的一个实例,它指的是JSP实现类的实例.

９．exception 

        是java.lang.Throwable类的一个实例,它指的是运行时的异常,也就是被调用的错误页面的结果,只有在错误页面(在指令里有isErrorPage=true的页面中)才可以使用

林光炎 2009-06-04 10:59 发表评论

]]>