M无垠专~IJ软育7@

一、引子

我们去科技市场为自己的机器添加点奢侈的配件，很多DIYer都喜欢去找代理商，因为在代理商那里拿到的东西不仅质量有保证，而且价格和售后服务上都会好很多。客户通过代理商得到了自己想要的东西，而且还享受到了代理商额外的服务；而生产厂商通过代理商将自己的产品推广出去，而且可以将一些销售服务的任务交给代理商来完成（当然代理商要和厂商来共同分担风险，分配利润），这样自己就可以花更多的心思在产品的设计和生产上了。

在美国，任何企业的产品要想拿到市场上去卖就必须经过代理商这一个环节，否则就是非法的。看来代理商在商业运作中起着很关键的作用。

不小心把话题扯远了，回过头来，那么在我们的面向对象的程序设计中，会不会有代理商这样的角色呢？来看这篇文章的人肯定不会说：没有！

那么就跟着这篇文章来看看代理模式的奇妙吧~~~~

二、定义和分类

A：What’s 代理模式 in English ?

B：It is Proxy or Surrogate !

代理模式在设计模式中的定义就是：为其他对象提供一种代理以控制对这个对象的访问。说白了就是，在一些情况下客户不想或者不能直接引用一个对象，而代理对象可以在客户和目标对象之间起到中介作用，去掉客户不能看到的内容和服务或者增添客户需要的额外服务。
    那么什么时候要使用代理模式呢？在对已有的方法进行使用的时候出现需要对原有方法进行改进或者修改，这时候有两种改进选择：修改原有方法来适应现在的使用方式，或者使用一个“第三者”方法来调用原有的方法并且对方法产生的结果进行一定的控制。第一种方法是明显违背了“对扩展开放、对修改关闭”（开闭原则），而且在原来方法中作修改可能使得原来类的功能变得模糊和多元化（就像现在企业多元化一样），而使用第二种方式可以将功能划分的更加清晰，有助于后面的维护。所以在一定程度上第二种方式是一个比较好的选择！
    当然，话又说回来了，如果是一个很小的系统，功能也不是很繁杂，那么使用代理模式可能就显得臃肿，不如第一种方式来的快捷。这就像一个三口之家，家务活全由家庭主妇或者一个保姆来完成是比较合理的，根本不需要雇上好几个保姆层层代理:)

根据《Java与模式》书中对代理模式的分类，代理模式分为8种，这里将几种常见的、重要的列举如下：

1.        远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。比如：你可以将一个在世界某个角落一台机器通过代理假象成你局域网中的一部分。

2.        虚拟（Virtual）代理：根据需要将一个资源消耗很大或者比较复杂的对象延迟的真正需要时才创建。比如：如果一个很大的图片，需要花费很长时间才能显示出来，那么当这个图片包含在文档中时，使用编辑器或浏览器打开这个文档，这个大图片可能就影响了文档的阅读，这时需要做个图片Proxy来代替真正的图片。

3.        保护（Protect or Access）代理：控制对一个对象的访问权限。比如：在论坛中，不同的身份登陆，拥有的权限是不同的，使用代理模式可以控制权限（当然，使用别的方式也可以实现）。

4.        智能引用（Smart Reference）代理：提供比对目标对象额外的服务。比如：纪录访问的流量（这是个再简单不过的例子），提供一些友情提示等等。

代理模式是一种比较有用的模式，从几个类的“小结构”到庞大系统的“大结构”都可以看到它的影子。

三、结构

代理模式中的“代理商”要想实现代理任务，就必须和被代理的“厂商”使用共同的接口（你可以想象为产品）。所以自然而然你会想到在java中使用一个抽象类或者接口（推荐）来实现这个共同的接口。于是代理模式就有三个角色组成了：

1．抽象主题角色：声明了真实主题和代理主题的共同接口。

2．代理主题角色：内部包含对真实主题的引用，并且提供和真实主题角色相同的接口。

3．真实主题角色：定义真实的对象。

使用类图来表示下三者间的关系如下：

  
    当然，图上所示的是代理模式中的一个具体情况。而代理模式可以非常灵活的使用其他方式来实现，这样就与图上所示有很大的区别。

也许，现在你已经对代理模式已经有了一个宏观的认识了，下面我们来看看怎么实际的使用代理模式。

四、举例

以论坛中已注册用户和游客的权限不同来作为第一个例子：已注册的用户拥有发帖，修改自己的注册信息，修改自己的帖子等功能；而游客只能看到别人发的帖子，没有其他权限。为了简化代码，更好的显示出代理模式的骨架，我们这里只实现发帖权限的控制。

首先我们先实现一个抽象主题角色MyForum，里面定义了真实主题和代理主题的共同接口——发帖功能。

代码如下：

public interface MyForum

{

       public void AddFile();

}

这样，真实主题角色和代理主题角色都要实现这个接口。其中真实的主题角色基本就是将这个接口的方法内容填充进来。所以在这里就不再赘述它的实现。我们把主要的精力放到关键的代理主题角色上。代理主题角色代码大体如下：

public class MyForumProxy implements MyForum

{

       private RealMyForum forum ;

       private int permission ;        //权限值

       public MyForumProxy(int permission)

       {

            forum = new RealMyForum() 
                  this.permission = permission ;

       }

       //实现的接口

       public void AddFile()

       {

              //满足权限设置的时候才能够执行操作

              //Constants是一个常量类

if(Constants.ASSOCIATOR == permission)

              {

                     forum.AddFile();

              }

              else

                     System.out.println("You are not a associator of MyForum ,please registe!");

       }

}

这样就实现了代理模式的功能。当然你也可以在这个代理类上添加自己的方法来实现额外的服务，比如统计帖子的浏览次数，记录用户的登录情况等等。

还有一个很常见的代理模式的使用例子就是对大幅图片浏览的控制。在我们常见的网站上面浏览图文的信息时，不知道你有没有注意到，图片位置放置的是经过缩小的，当有人要仔细的查看这个图片时，可以通过点击图片来激活一个链接，在一个新的网页打开要看的图片 。这样对于提高浏览速度是很有好处的，因为不是每个人都要去看仔细图上的信息。这种情况就可以使用代理模式来全面实现。这里我将思路表述出来，至于实现由于工作原因，就不表述了，至于这种方式在B/S模式下的真实可行性，我没有确认过，只是凭空的想象。如果不是可行的方式，那这个例子可以放到一个C/S下来实现，这个是绝对没有问题的，而且在很多介绍设计模式的书和文章中使用。两种方式的实现有兴趣的可以来尝试一下：）
    我们在浏览器中访问网页时是调用的不是真实的装载图片的方法，而是在代理对象中的方法，在这个对象中，先使用一个线程向浏览器装载了一个缩小版的图片，而在后台使用另一个线程来调用真实的装载大图片的方法将图片加载到本地，当你要浏览这个图片的时候，将其在新的网页中显示出来。当然如果在你想浏览的时候图片尚未加载成功，可以再启动一个线程来显示提示信息，直到加载成功。   
    这样代理模式的功能就在上面体现的淋漓尽致——通过代理来将真实图片的加载放到后台来操作，使其不影响前台的浏览。

五、总结

代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度。不过一定要记住前面讲的使用代理模式的条件，不然的话使用了代理模式不但不会有好的效果，说不定还会出问题的~~

    三、request 对象
    request 对象包含所有请求的信息，如：请求的来源、标头、cookies和请求相关的参数值等等。
    request 对象实现javax.servlet.http.HttpServletRequest接口的，所提供的方法可以将它分为四大类：
    1.储存和取得属性方法；
        void setAttribute(String name, Object value)    设定name属性的值为value
        Enumeration getAttributeNamesInScope(int scope)    取得所有scope 范围的属性
        Object getAttribute(String name)                取得name 属性的值
        void removeAttribute(String name)                移除name 属性的值
    2.取得请求参数的方法
        String getParameter(String name)                取得name 的参数值
        Enumeration getParameterNames( )                取得所有的参数名称
        String [] getParameterValues(String name)         取得所有name 的参数值
        Map getParameterMap( )                             取得一个要求参数的Map
    3.能够取得请求HTTP 标头的方法
        String getHeader(String name)                     取得name 的标头
        Enumeration getHeaderNames()                     取得所有的标头名称
        Enumeration getHeaders(String name)             取得所有name 的标头
        int getIntHeader(String name)                     取得整数类型name 的标头
        long getDateHeader(String name)                 取得日期类型name 的标头
        Cookie [] getCookies( )                         取得与请求有关的cookies
    4.其他的方法
        String getContextPath( )                         取得Context 路径(即站台名称)
        String getMethod( )                             取得HTTP 的方法(GET、POST)
        String getProtocol( )                             取得使用的协议 (HTTP/1.1、HTTP/1.0 )
        String getQueryString( )                        取得请求的参数字符串，不过，HTTP的方法必须为GET
        String getRequestedSessionId( )                 取得用户端的Session ID
        String getRequestURI( )                            取得请求的URL，但是不包括请求的参数字符串
        String getRemoteAddr( )                            取得用户的IP 地址
        String getRemoteHost( )                            取得用户的主机名称
        int getRemotePort( )                            取得用户的主机端口
        String getRemoteUser( )                         取得用户的名称
        void etCharacterEncoding(String    encoding)        设定编码格式，用来解决窗体传递中文的问题

    四、response 对象
    response 对象主要将JSP 处理数据后的结果传回到客户端。
    response 对象是实现javax.servlet.http.HttpServletResponse 接口。response对象所提供的方法。
    1.设定表头的方法
        void addCookie(Cookie cookie)                     新增cookie
        void addDateHeader(String name, long date)        新增long类型的值到name标头
        void addHeader(String name, String value)        新增String类型的值到name标头
        void addIntHeader(String name, int value)         新增int类型的值到name标头
        void setDateHeader(String name, long date)        指定long类型的值到name标头
        void setHeader(String name, String value)        指定String类型的值到name标头
        void setIntHeader(String name, int value)         指定int类型的值到name标头
    2.设定响应状态码的方法
        void sendError(int sc)                             传送状态码(status code)
        void sendError(int sc, String msg)                传送状态码和错误信息
        void setStatus(int sc)                             设定状态码
    3.用来URL 重写(rewriting)的方法   
        String encodeRedirectURL(String    url)            对使用sendRedirect( )方法的URL予以编码

    五、out 对象
    out 对象能把结果输出到网页上。
    out主要是用来控制管理输出的缓冲区(buffer)和输出流(output stream)。
        void clear( )                                     清除输出缓冲区的内容
        void clearBuffer( )                             清除输出缓冲区的内容
        void close( )                                     关闭输出流，清除所有的内容
        int getBufferSize( )                             取得目前缓冲区的大小(KB)
        int getRemaining( )                             取得目前使用后还剩下的缓冲区大小(KB)
        boolean isAutoFlush( )                            回传true表示缓冲区满时会自动清除；false表示不会自动清除并且产生异常处理
       
    六、session 对象
    session对象表示目前个别用户的会话(session)状况。
    session对象实现javax.servlet.http.HttpSession接口，HttpSession接口所提供的方法
        long getCreationTime()                            取得session产生的时间，单位是毫秒
        String getId()                                     取得session 的ID
        long getLastAccessedTime()                        取得用户最后通过这个session送出请求的时间
        long getMaxInactiveInterval()                    取得最大session不活动的时间，若超过这时间，session 将会失效
        void invalidate()                                取消session 对象，并将对象存放的内容完全抛弃
        boolean isNew()                                    判断session 是否为"新"的
        void setMaxInactiveInterval(int    interval)        设定最大session不活动的时间，若超过这时间，session 将会失效

    七、application对象
    application对象最常被使用在存取环境的信息。
    因为环境的信息通常都储存在ServletContext中，所以常利用application对象来存取ServletContext中的信息。
    application 对象实现javax.servlet.ServletContext 接口，ServletContext接口容器所提供的方法
        int getMajorVersion( )                             取得Container主要的Servlet API版本
        int getMinorVersion( )                             取得Container次要的Servlet API 版本
        String getServerInfo( )                         取得Container的名称和版本
        String getMimeType(String file)                 取得指定文件的MIME 类型
        ServletContext getContext(String uripath)        取得指定Local URL的Application context
        String getRealPath(String path)                 取得本地端path的绝对路径
        void log(String message)                         将信息写入log文件中
        void log(String message, Throwable throwable)    将stack trace 所产生的异常信息写入log文件中

    八、pageContext对象
    pageContext对象能够存取其他隐含对象。
    1.pageContext对象存取其他隐含对象属性的方法，此时需要指定范围的参数。
        Object getAttribute(String name, int scope)
        Enumeration getAttributeNamesInScope(int scope)
        void removeAttribute(String name, int scope)
        void setAttribute(String name, Object value, int scope)
    范围参数有四个，分别代表四种范围：PAGE_SCOPE、REQUEST_SCOPE、SESSION_SCOPE、APPLICATION_SCOPE
    2.PageContext对象取得其他隐含对象的方法
        Exception getException( )                        回传目前网页的异常，不过此网页要为error page，
        JspWriter getOut( )                             回传目前网页的输出流，例如：out
        Object getPage( )                                回传目前网页的Servlet 实体(instance)，例如：page
        ServletRequest getRequest( )                    回传目前网页的请求，例如：request
        ServletResponse getResponse( )                    回传目前网页的响应，例如：response
        ServletConfig getServletConfig( )                回传目前此网页的ServletConfig 对象，例如：config
        ServletContext getServletContext( )                回传目前此网页的执行环境(context)，例如：application
        HttpSession getSession( )                        回传和目前网页有联系的会话(session)，例如：session
    3.PageContext对象提供取得属性的方法
        Object getAttribute(String name, int scope)        回传name 属性，范围为scope的属性对象，回传类型为Object
        Enumeration getAttributeNamesInScope(int scope)    回传所有属性范围为scope 的属性名称，回传类型为Enumeration
        int getAttributesScope(String name)             回传属性名称为name 的属性范围
        void removeAttribute(String name)                 移除属性名称为name 的属性对象
        void removeAttribute(String name, int scope)    移除属性名称为name，范围为scope 的属性对象
        void setAttribute(String name, Object value, int scope)        指定属性对象的名称为name、值为value、范围为scope
        Object findAttribute(String name)                寻找在所有范围中属性名称为name 的属性对象

    九、exception对象
    若要使用exception 对象时，必须在page 指令中设定。<%@ page isErrorPage="true" %>才能使用。
    exception提供的三个方法：
        getMessage( )
        getLocalizedMessage( )、
        printStackTrace(new java.io.PrintWriter(out)) 

正如许多以前在同步、可靠性、可伸缩性和安全性方面的未知问题一样，分布式应用程序潜在的问题也是不断增长的。一种解决方案是建立在松散耦合组件基础上的消息传递系统，这些组件之间通过消息进行通信。

Java 消息服务提供了一致的 API 集合，让开发人员可以访问许多消息传递系统产品的公共特性。

什么是消息传递系统？
从它的本质上讲，消息传递系统允许不同的非耦合应用程序以异步方式进行可靠通信。消息传递系统体系结构一般用各个组件间的点对点关系代替客户端/服务器模型，其中每个点可以发送消息到其他点，或从其他点接收消息。

相对于更加传统的分布式计算模型，消息传递系统提供了许多强大的优势。首先，它们倡议在消息消费者和消息生产者之间进行“松散耦合”。在生产者和消费者之间存在着高级匿名：对于消息消费者，它不关心 谁 产生消息，在网络上生产者在 哪里，或者消息是 何时 产生的。

这使得可以构建动态、可靠和灵活的系统，由此可以修改子应用程序的整体组合，而不会影响到系统的其余部分。 消息传递系统的其他优势包括高可伸缩性（商业实现鼓吹可以支持好几万个客户端，以及支持每秒进行好几万个操作）、容易集成到异构网络以及由于减少了单点故障而提高了可靠性。

由于消息传递系统固有的可靠性和可伸缩性，所以它们用于解决许多商业和计算科学问题。例如，它们是这样的一些不同的应用程序的基础：工作流、网络管理、通信服务（通过 IP 的语音、有声邮件、寻呼机和电子邮件）、客户服务、天气预报和供应链管理等系统。此外，消息传递系统是无价的，因为它作为“glue”（胶水）把完全不同的系统联系在一起，使之能够合并和获取消息。

消息系统类型
通常使用两种消息传递系统模型。

发布/订阅
发布/订阅 (pub/sub) 消息传递系统支持事件驱动模型，在这种模型中，信息消费者和生产者参与消息的传输。生产者“发布”事件，而消费者“订阅”感兴趣的事件并消费事件。生产者把消息把与特定主题关联起来，然后消息传递系统根据消费者所注册的感兴趣主题，把消息路由给消费者。

点对点
在点对点消息传递系统中，消息是被路由到各个消费者的，该消费者维护“传入”消息队列。消息传递应用程序发送消息到指定队列，然后客户端从队列中检索消息。 供应商经常会支持点对点模型或发布/订阅消息传递模型，或者同时支持这两种模型。

既然已经从大体上认识了消息系统，现在让我们来看一下 Java 开发人员是如何可以利用它们的能力的。

Java 消息服务
Java 消息服务是 J2EE (Java 2 Enterprise Edition) 套件的一部分，它提供了标准 API，Java 开发人员可以使用这些 API 来访问企业消息系统的共同特性。JMS 支持发布/订阅和点对点模型，并允许创建由任意 Java 对象组成的消息类型。

设计目标
JMS 的基本设计目标是为了提供一组一致的接口，消息传递系统客户端可以独立地使用这些接口，而不必关心基础消息系统的提供商。 这样，客户端应用程序不仅可以跨计算机体系结构和操作系统进行移植，而且也可以跨消息传递产品进行移植。写到 JMS 的客户端应用程序将正常工作，而不用在所有符合 JMS 的消息传递系统上做修改（这可以与组件所运行的基础中间件上的 Enterprise Java Beans 组件的独立性进行比较）。

JMS 也设计成：

最小化消息传递系统提供商为其产品实现 JMS API 所需的工作量。
提供了普通消息传递系统的大多数功能。
许多消息系统提供商已经为它们的产品实现了 JMS，允许 Java 访问它们系统的功能。

JMS 客户端可以使用 Java 设施
由于 JMS 客户端是基于 Java 的，因此它们可以利用现有的 Java API，比如：用于数据库访问的 JDBC、JavaBeans 组件模型、用于命名服务的 JNDI、用于客户端事务控制的 JTA 或用于企业应用程序服务的任何 J2SE 和 J2EE API。

JMS 细节
现在，我们从消息开始，来看一下使用 JMS 构建消息传递系统客户端的细节。

什么是消息？
在消息传递系统中，应用程序之间的通信点是消息本身，因此使用 JMS 的开发人员必须理解消息。

尽管消息传递系统之间消息定义区别甚大，但 JMS 提供了统一的方式用于描述和访问消息。JMS 消息由三部分组成：

消息标题
用于消息标识。例如，标题用于确定指定的消息是否适合于“订阅者”。
属性
用于特定于应用程序、特定于提供商及可选的标题字段。
消息体
保存消息的内容。支持几种格式，其中包括：TextMessages——用于包装简单的 String; 和 ObjectMessages——用于包装任意的 Java 对象（它们必须是可序列化的）。也支持其他的格式。
TextMessages
TextMessage 用于包装简单的 String 对象。在只传递字符串的情形下，这是有用的。期望许多消息传递系统将以 XML 为基础，TextMessages 是它们的自然容器。

创建 TextMessage 对象是简单的，如下面两行代码所指出的那样：

TextMessage message =
session.createMessage();
message.setText("hello world");

（在下一节，我们将看到 session 对象）。

以这种方式创建的 TextMessage 准备发布到消息传递系统中。

ObjectMessages
顾名思义，ObjectMessage 是包装了 Java 对象的消息。任何可序列化的 Java 对象均可用作 ObjectMessage。如果多个对象必须在单个消息中传输，那么可以使用包含几个可序列化对象的 Collection 对象（比如 List 或 Set）。

下面展示了如何创建 Object 消息：

ObjectMessage message = session.createObjectMessage();
message.setObject(myObject);

关于 JNDI
像许多 J2EE API 一样，JMS 利用了 JNDI（Java 命名和目录接口）来发现所需资源。详细讨论 JNDI 超出了本文的范围，但可从如下地址找到更多的进一步信息：Java 命名和目录接口 (JNDI)。

构建 JMS 客户端
可以遵循下面的基本步骤来构建典型的 JMS 客户端：

创建到消息传递系统提供商的连接。
创建会话用于发送和接收消息。
创建 MessageProducers 和 MessageConsumers 来创建或接收消息。
一旦这些步骤执行完毕，消息生产的客户端将创建消息，并把它们发布到主题，而消息消费的客户端将侦听与主题有关的消息，并在它们到达时消费它们。

为了详细展示它是如何工作的，我们研究了典型的消息生产者，它用于在 pub/sub 消息传递系统中把消息发布到特定的主题。注意，为简洁起见，省略了所有异常处理代码。

创建连接
连接为客户端提供了对基础消息传递系统的访问，并执行资源分配和管理。连接是使用 ConnectionFactory 创建的，而 ConnectionFactory 通常是使用 JNDI 查找的。

下面这些代码展示了创建连接过程中涉及的一些步骤：

Context messaging = new InitialContext();
// get JNDI context
TopicConnectionFactory topicConnectionFactory =
(TopicConnectionFactory)
messaging.lookup("TopicConnectionFactory");
TopicConnection topicConnection =
topicConnectionFactory.createTopicConnection();

创建会话
会话是轻量级 JMS 对象，它提供了用于生产和消费消息的上下文。会话用于生成消息生产者和消息消费者，以及用于生成消息本身。

TopicSession session =
topicConnection.createTopicSession(false,
Session.CLIENT_ACKNOWLEDGE);

createTopicSession() 的两个参数控制事务和消息的确认。

查找主题
主题（也称标题、组或频道）是通过 JNDI 来查找的。主题标识了发送中或接收中的消息。在发布/阅系统中，订阅者订阅了指定的主题，而发布者把主题与它们发布的消息关联。

这里我们创建了一个称为“WeatherData”的主题。

Topic weatherTopic = messaging.lookup("WeatherData");

启动连接
在上面的初始化过程中，为了防止初始化期间出现不可预知的行为，消息流是被禁止的。一旦初始化完成，必须告诉连接开始消息流。

topicConnection.start();

创建消息生产者
在发布/订阅领域中，生产者把消息发布到指定主题。下面代码展示了发布者的创建及后续的简单文本消息的生成和发布。

TopicPublisher publisher =
session.createPublisher(weatherData);
TextMessage message = session.createMessage();
message.setText("temperature: 35 degrees");

publisher.publish(message);

创建订阅者及点对点系统的 JMS 客户端遵循相似的过程。可以在 [1] 中找到这一过程的完整细节。

结束语
我们已经看到在使用 JMS 来构建基于消息传递的应用程序的过程中涉及的基本概念。在编写 JMS 代码之前，你将需要访问符合 JMS 的消息传递系统。可从如下地址获取符合 JMS 的供应商的列表：

JMS 供应商

创建和构建基于 JMS 的应用程序是简单的，可是它为构建强大、可伸缩和高可靠的分布式系统提供了基础。

注意，JMS 远远比本文讨论的要复杂，并为下面的这些提供了支持：管理、安全、错误处理和恢复、优化、分布式事务、消息排序和消息确认等。

有关 Java Message Service 的进一步信息和文档，请参阅：

Java Message Service 文档

参考资料
本文中的许多内容是以 Java Message Service 文档 为基础的。

本文的再版须有 SunServer 许可。

BeanUtils
Commons-BeanUtils 提供对 Java 反射和自省API的包装

Betwixt
Betwixt提供将 JavaBean 映射至 XML 文档，以及相反映射的服务.

Chain
Chain 提供实现组织复杂的处理流程的“责任链模式”.

CLI
CLI 提供针对命令行参数，选项，选项组，强制选项等的简单API.

Codec
Codec 包含一些通用的编码解码算法。包括一些语音编码器， Hex, Base64, 以及URL encoder.

Collections
Commons-Collections 提供一个类包来扩展和增加标准的 Java Collection框架

Configuration
Commons-Configuration 工具对各种各式的配置和参考文件提供读取帮助.

Daemon
一种 unix-daemon-like java 代码的替代机制

DBCP
Commons-DBCP 提供数据库连接池服务

DbUtils
DbUtils 是一个 JDBC helper 类库，完成数据库任务的简单的资源清除代码.

Digester
Commons-Digester 是一个 XML-Java对象的映射工具，用于解析 XML配置文件.

Discovery
Commons-Discovery 提供工具来定位资源 (包括类) ，通过使用各种模式来映射服务/引用名称和资源名称。.

EL
Commons-EL 提供在JSP2.0规范中定义的EL表达式的解释器.

FileUpload
FileUpload 使得在你可以在应用和Servlet中容易的加入强大和高性能的文件上传能力

HttpClient
Commons-HttpClient 提供了可以工作于HTTP协议客户端的一个框架.

IO
IO 是一个 I/O 工具集

Jelly
Jelly是一个基于 XML 的脚本和处理引擎。 Jelly 借鉴了 JSP 定指标签，Velocity, Cocoon和Xdoclet中的脚本引擎的许多优点。Jelly 可以用在命令行， Ant 或者 Servlet之中。

Jexl
Jexl是一个表达式语言，通过借鉴来自于Velocity的经验扩展了JSTL定义的表达式语言。.

JXPath
Commons-JXPath 提供了使用Xpath语法操纵符合Java类命名规范的 JavaBeans的工具。也支持 maps, DOM 和其他对象模型。.

Lang
Commons-Lang 提供了许多许多通用的工具类集，提供了一些java.lang中类的扩展功能

Latka
Commons-Latka 是一个HTTP 功能测试包，用于自动化的QA,验收和衰减测试.

Launcher
Launcher 组件是一个交叉平台的Java 应用载入器。 Commons-launcher 消除了需要批处理或者Shell脚本来载入Java 类。.原始的 Java 类来自于Jakarta Tomcat 4.0 项目

Logging
Commons-Logging 是一个各种 logging API实现的包裹类.

Math
Math 是一个轻量的，自包含的数学和统计组件，解决了许多非常通用但没有及时出现在Java标准语言中的实践问题.

Modeler
Commons-Modeler 提供了建模兼容JMX规范的 Mbean的机制.

Net
Net 是一个网络工具集，基于 NetComponents 代码，包括 FTP 客户端等等。

Pool
Commons-Pool 提供了通用对象池接口，一个用于创建模块化对象池的工具包，以及通常的对象池实现.

Primitives
Commons-Primitives提供了一个更小，更快和更易使用的对Java基本类型的支持。当前主要是针对基本类型的 collection。.

Validator
The commons-validator提供了一个简单的，可扩展的框架来在一个XML文件中定义校验器 (校验方法)和校验规则。支持校验规则的和错误消息的国际化。

HTTP 协议可能是现在 Internet 上使用得最多、最重要的协议了，越来越多的 Java 应用程序需要直接通过 HTTP 协议来访问网络资源。虽然在 JDK 的 java.net 包中已经提供了访问 HTTP 协议的基本功能，但是对于大部分应用程序来说，JDK 库本身提供的功能还不够丰富和灵活。HttpClient 是 Apache Jakarta Common 下的子项目，用来提供高效的、最新的、功能丰富的支持 HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本和建议。HttpClient 已经应用在很多的项目中，比如 Apache Jakarta 上很著名的另外两个开源项目 Cactus 和 HTMLUnit 都使用了 HttpClient，更多使用 HttpClient 的应用可以参见http://wiki.apache.org/jakarta-httpclient/HttpClientPowered。HttpClient 项目非常活跃，使用的人还是非常多的。目前 HttpClient 版本是在 2005.10.11 发布的 3.0 RC4 。

HttpClient 功能介绍

以下列出的是 HttpClient 提供的主要的功能，要知道更多详细的功能可以参见 HttpClient 的主页。

• 实现了所有 HTTP 的方法（GET,POST,PUT,HEAD 等）
• 支持自动转向
• 支持 HTTPS 协议
• 支持代理服务器等

下面将逐一介绍怎样使用这些功能。首先，我们必须安装好 HttpClient。

• HttpClient 可以在http://jakarta.apache.org/commons/httpclient/downloads.html下载
• HttpClient 用到了 Apache Jakarta common 下的子项目 logging，你可以从这个地址http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi下载到 common logging，从下载后的压缩包中取出 commons-logging.jar 加到 CLASSPATH 中
• HttpClient 用到了 Apache Jakarta common 下的子项目 codec，你可以从这个地址http://jakarta.apache.org/site/downloads/downloads_commons-codec.cgi 下载到最新的 common codec，从下载后的压缩包中取出 commons-codec-1.x.jar 加到 CLASSPATH 中

HttpClient 基本功能的使用

GET 方法

使用 HttpClient 需要以下 6 个步骤：

1. 创建 HttpClient 的实例

2. 创建某种连接方法的实例，在这里是 GetMethod。在 GetMethod 的构造函数中传入待连接的地址

3. 调用第一步中创建好的实例的 execute 方法来执行第二步中创建好的 method 实例

4. 读 response

5. 释放连接。无论执行方法是否成功，都必须释放连接

6. 对得到后的内容进行处理

根据以上步骤，我们来编写用GET方法来取得某网页内容的代码。

• 大部分情况下 HttpClient 默认的构造函数已经足够使用。

  HttpClient httpClient = new HttpClient();

  
  
• 创建GET方法的实例。在GET方法的构造函数中传入待连接的地址即可。用GetMethod将会自动处理转发过程，如果想要把自动处理转发过程去掉的话，可以调用方法setFollowRedirects(false)。

  GetMethod getMethod = new GetMethod("http://www.ibm.com/");

  
  
• 调用实例httpClient的executeMethod方法来执行getMethod。由于是执行在网络上的程序，在运行executeMethod方法的时候，需要处理两个异常，分别是HttpException和IOException。引起第一种异常的原因主要可能是在构造getMethod的时候传入的协议不对，比如不小心将"http"写成"htp"，或者服务器端返回的内容不正常等，并且该异常发生是不可恢复的；第二种异常一般是由于网络原因引起的异常，对于这种异常 （IOException），HttpClient会根据你指定的恢复策略自动试着重新执行executeMethod方法。HttpClient的恢复策略可以自定义（通过实现接口HttpMethodRetryHandler来实现）。通过httpClient的方法setParameter设置你实现的恢复策略，本文中使用的是系统提供的默认恢复策略，该策略在碰到第二类异常的时候将自动重试3次。executeMethod返回值是一个整数，表示了执行该方法后服务器返回的状态码，该状态码能表示出该方法执行是否成功、需要认证或者页面发生了跳转（默认状态下GetMethod的实例是自动处理跳转的）等。

  //设置成了默认的恢复策略，在发生异常时候将自动重试3次，在这里你也可以设置成自定义的恢复策略 getMethod.getParams().setParameter(HttpMethodParams.RETRY_HANDLER, new DefaultHttpMethodRetryHandler()); //执行getMethod int statusCode = client.executeMethod(getMethod); if (statusCode != HttpStatus.SC_OK) { System.err.println("Method failed: " + getMethod.getStatusLine()); }

  
  
• 在返回的状态码正确后，即可取得内容。取得目标地址的内容有三种方法：第一种，getResponseBody，该方法返回的是目标的二进制的byte流；第二种，getResponseBodyAsString，这个方法返回的是String类型，值得注意的是该方法返回的String的编码是根据系统默认的编码方式，所以返回的String值可能编码类型有误，在本文的"字符编码"部分中将对此做详细介绍；第三种，getResponseBodyAsStream，这个方法对于目标地址中有大量数据需要传输是最佳的。在这里我们使用了最简单的getResponseBody方法。

  byte[] responseBody = method.getResponseBody();

  
  
• 释放连接。无论执行方法是否成功，都必须释放连接。

  method.releaseConnection();

  
  
• 处理内容。在这一步中根据你的需要处理内容，在例子中只是简单的将内容打印到控制台。

  System.out.println(new String(responseBody));

  
  

下面是程序的完整代码，这些代码也可在附件中的test.GetSample中找到。

												
														package test;
import java.io.IOException;
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.params.HttpMethodParams;

public class GetSample{
  public static void main(String[] args) {
  //构造HttpClient的实例
  HttpClient httpClient = new HttpClient();
  //创建GET方法的实例
  GetMethod getMethod = new GetMethod("http://www.ibm.com");
  //使用系统提供的默认的恢复策略
  getMethod.getParams().setParameter(HttpMethodParams.RETRY_HANDLER,
    new DefaultHttpMethodRetryHandler());
  try {
   //执行getMethod
   int statusCode = httpClient.executeMethod(getMethod);
   if (statusCode != HttpStatus.SC_OK) {
    System.err.println("Method failed: "
      + getMethod.getStatusLine());
   }
   //读取内容 
   byte[] responseBody = getMethod.getResponseBody();
   //处理内容
   System.out.println(new String(responseBody));
  } catch (HttpException e) {
   //发生致命的异常，可能是协议不对或者返回的内容有问题
   System.out.println("Please check your provided http address!");
   e.printStackTrace();
  } catch (IOException e) {
   //发生网络异常
   e.printStackTrace();
  } finally {
   //释放连接
   getMethod.releaseConnection();
  }
 }
}

												
										

POST方法

根据RFC2616，对POST的解释如下：POST方法用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列（Request-Line）中请求URI所指定资源的附加新子项。POST被设计成用统一的方法实现下列功能：

• 对现有资源的注释（Annotation of existing resources）
• 向电子公告栏、新闻组，邮件列表或类似讨论组发送消息
• 提交数据块，如将表单的结果提交给数据处理过程
• 通过附加操作来扩展数据库

调用HttpClient中的PostMethod与GetMethod类似，除了设置PostMethod的实例与GetMethod有些不同之外，剩下的步骤都差不多。在下面的例子中，省去了与GetMethod相同的步骤，只说明与上面不同的地方，并以登录清华大学BBS为例子进行说明。

• 构造PostMethod之前的步骤都相同，与GetMethod一样，构造PostMethod也需要一个URI参数，在本例中，登录的地址是http://www.newsmth.net/bbslogin2.php。在创建了PostMethod的实例之后，需要给method实例填充表单的值，在BBS的登录表单中需要有两个域，第一个是用户名（域名叫id），第二个是密码（域名叫passwd）。表单中的域用类NameValuePair来表示，该类的构造函数第一个参数是域名，第二参数是该域的值；将表单所有的值设置到PostMethod中用方法setRequestBody。另外由于BBS登录成功后会转向另外一个页面，但是HttpClient对于要求接受后继服务的请求，比如POST和PUT，不支持自动转发，因此需要自己对页面转向做处理。具体的页面转向处理请参见下面的"自动转向"部分。代码如下：

  String url = "http://www.newsmth.net/bbslogin2.php"; PostMethod postMethod = new PostMethod(url); // 填入各个表单域的值 NameValuePair[] data = { new NameValuePair("id", "youUserName"), new NameValuePair("passwd", "yourPwd") }; // 将表单的值放入postMethod中 postMethod.setRequestBody(data); // 执行postMethod int statusCode = httpClient.executeMethod(postMethod); // HttpClient对于要求接受后继服务的请求，象POST和PUT等不能自动处理转发 // 301或者302 if (statusCode == HttpStatus.SC_MOVED_PERMANENTLY || statusCode == HttpStatus.SC_MOVED_TEMPORARILY) { // 从头中取出转向的地址 Header locationHeader = postMethod.getResponseHeader("location"); String location = null; if (locationHeader != null) { location = locationHeader.getValue(); System.out.println("The page was redirected to:" + location); } else { System.err.println("Location field value is null."); } return; }

  
  

完整的程序代码请参见附件中的test.PostSample

使用HttpClient过程中常见的一些问题

下面介绍在使用HttpClient过程中常见的一些问题。

字符编码

某目标页的编码可能出现在两个地方，第一个地方是服务器返回的http头中，另外一个地方是得到的html/xml页面中。

• 在http头的Content-Type字段可能会包含字符编码信息。例如可能返回的头会包含这样子的信息：Content-Type: text/html; charset=UTF-8。这个头信息表明该页的编码是UTF-8，但是服务器返回的头信息未必与内容能匹配上。比如对于一些双字节语言国家，可能服务器返回的编码类型是UTF-8，但真正的内容却不是UTF-8编码的，因此需要在另外的地方去得到页面的编码信息；但是如果服务器返回的编码不是UTF-8，而是具体的一些编码，比如gb2312等，那服务器返回的可能是正确的编码信息。通过method对象的getResponseCharSet()方法就可以得到http头中的编码信息。
• 对于象xml或者html这样的文件，允许作者在页面中直接指定编码类型。比如在html中会有<meta http-equiv="Content-Type" content="text/html; charset=gb2312"/>这样的标签；或者在xml中会有<?xml version="1.0" encoding="gb2312"?>这样的标签，在这些情况下，可能与http头中返回的编码信息冲突，需要用户自己判断到底那种编码类型应该是真正的编码。

自动转向

根据RFC2616中对自动转向的定义，主要有两种：301和302。301表示永久的移走（Moved Permanently），当返回的是301，则表示请求的资源已经被移到一个固定的新地方，任何向该地址发起请求都会被转到新的地址上。302表示暂时的转向，比如在服务器端的servlet程序调用了sendRedirect方法，则在客户端就会得到一个302的代码，这时服务器返回的头信息中location的值就是sendRedirect转向的目标地址。

HttpClient支持自动转向处理，但是象POST和PUT方式这种要求接受后继服务的请求方式，暂时不支持自动转向，因此如果碰到POST方式提交后返回的是301或者302的话需要自己处理。就像刚才在POSTMethod中举的例子：如果想进入登录BBS后的页面，必须重新发起登录的请求，请求的地址可以在头字段location中得到。不过需要注意的是，有时候location返回的可能是相对路径，因此需要对location返回的值做一些处理才可以发起向新地址的请求。

另外除了在头中包含的信息可能使页面发生重定向外，在页面中也有可能会发生页面的重定向。引起页面自动转发的标签是：<meta http-equiv="refresh" content="5; url=http://www.ibm.com/us">。如果你想在程序中也处理这种情况的话得自己分析页面来实现转向。需要注意的是，在上面那个标签中url的值也可以是一个相对地址，如果是这样的话，需要对它做一些处理后才可以转发。

处理HTTPS协议

HttpClient提供了对SSL的支持，在使用SSL之前必须安装JSSE。在Sun提供的1.4以后的版本中，JSSE已经集成到JDK中，如果你使用的是JDK1.4以前的版本则必须安装JSSE。JSSE不同的厂家有不同的实现。下面介绍怎么使用HttpClient来打开Https连接。这里有两种方法可以打开https连接，第一种就是得到服务器颁发的证书，然后导入到本地的keystore中；另外一种办法就是通过扩展HttpClient的类来实现自动接受证书。

方法1，取得证书，并导入本地的keystore：

• 安装JSSE （如果你使用的JDK版本是1.4或者1.4以上就可以跳过这一步）。本文以IBM的JSSE为例子说明。先到IBM网站上下载JSSE的安装包。然后解压开之后将ibmjsse.jar包拷贝到<java-home>\lib\ext\目录下。
• 取得并且导入证书。证书可以通过IE来获得：

  1． 用IE打开需要连接的https网址，会弹出如下对话框：

  
  
  
  

  2． 单击"View Certificate"，在弹出的对话框中选择"Details"，然后再单击"Copy to File"，根据提供的向导生成待访问网页的证书文件

  
  
  
  

  3． 向导第一步，欢迎界面，直接单击"Next"，

  
  
  
  

  4． 向导第二步，选择导出的文件格式，默认，单击"Next"，

  
  
  
  

  5． 向导第三步，输入导出的文件名，输入后，单击"Next"，

  
  
  
  

  6． 向导第四步，单击"Finish"，完成向导

  
  
  
  

  7． 最后弹出一个对话框，显示导出成功

  
  
  
  

• 用keytool工具把刚才导出的证书倒入本地keystore。Keytool命令在<java-home>\bin\下，打开命令行窗口，并到<java-home>\lib\security\目录下，运行下面的命令：

  keytool -import -noprompt -keystore cacerts -storepass changeit -alias yourEntry1 -file your.cer

  
  

  其中参数alias后跟的值是当前证书在keystore中的唯一标识符，但是大小写不区分；参数file后跟的是刚才通过IE导出的证书所在的路径和文件名；如果你想删除刚才导入到keystore的证书，可以用命令：

  keytool -delete -keystore cacerts -storepass changeit -alias yourEntry1

  
  
• 写程序访问https地址。如果想测试是否能连上https，只需要稍改一下GetSample例子，把请求的目标变成一个https地址。

  GetMethod getMethod = new GetMethod("https://www.yourdomain.com");

  
  

  运行该程序可能出现的问题：

  1. 抛出异常java.net.SocketException: Algorithm SSL not available。出现这个异常可能是因为没有加JSSEProvider，如果用的是IBM的JSSE Provider，在程序中加入这样的一行：

  if(Security.getProvider("com.ibm.jsse.IBMJSSEProvider") == null) Security.addProvider(new IBMJSSEProvider());

  
  

  或者也可以打开<java-home>\lib\security\java.security，在行

  security.provider.1=sun.security.provider.Sun security.provider.2=com.ibm.crypto.provider.IBMJCE

  
  

  后面加入security.provider.3=com.ibm.jsse.IBMJSSEProvider

  2. 抛出异常java.net.SocketException: SSL implementation not available。出现这个异常可能是你没有把ibmjsse.jar拷贝到<java-home>\lib\ext\目录下。

  3. 抛出异常javax.net.ssl.SSLHandshakeException: unknown certificate。出现这个异常表明你的JSSE应该已经安装正确，但是可能因为你没有把证书导入到当前运行JRE的keystore中，请按照前面介绍的步骤来导入你的证书。

方法２，扩展HttpClient类实现自动接受证书

因为这种方法自动接收所有证书，因此存在一定的安全问题，所以在使用这种方法前请仔细考虑您的系统的安全需求。具体的步骤如下：

• 提供一个自定义的socket factory（test.MySecureProtocolSocketFactory）。这个自定义的类必须实现接口org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory，在实现接口的类中调用自定义的X509TrustManager(test.MyX509TrustManager)，这两个类可以在随本文带的附件中得到
• 创建一个org.apache.commons.httpclient.protocol.Protocol的实例，指定协议名称和默认的端口号

  Protocol myhttps = new Protocol("https", new MySecureProtocolSocketFactory (), 443);

  
  
• 注册刚才创建的https协议对象

  Protocol.registerProtocol("https ", myhttps);

  
  
• 然后按照普通编程方式打开https的目标地址，代码请参见test.NoCertificationHttpsGetSample

处理代理服务器

HttpClient中使用代理服务器非常简单，调用HttpClient中setProxy方法就可以，方法的第一个参数是代理服务器地址，第二个参数是端口号。另外HttpClient也支持SOCKS代理。

												
														httpClient.getHostConfiguration().setProxy(hostName,port);

												
										

结论

从上面的介绍中，可以知道HttpClient对http协议支持非常好，使用起来很简单，版本更新快，功能也很强大，具有足够的灵活性和扩展性。对于想在Java应用中直接访问http资源的编程人员来说，HttpClient是一个不可多得的好工具。

参考资料

• 本文样码下载：src.zip
• Commons logging包含了各种各样的日志API的实现，读者可以通过站点http://jakarta.apache.org/commons/logging/得到详细的内容
  
  
• Commons codec包含了一些一般的解码/编码算法。包含了语音编码、十六进制、Base64和URL编码等，通过http://jakarta.apache.org/commons/codec/可以得到详细的内容
  
  
• rfc2616是关于HTTP/1.1的文档，可以在http://www.faqs.org/rfcs/rfc2616.html上得到详细的内容，另外rfc1945是关于HTTP/1.0的文档，通过http://www.faqs.org/rfcs/rfc1945.html可以得到详细内容
  
  
• SSL――SSL 是由 Netscape Communications Corporation 于 1994 年开发的，而 TLS V1.0 是由 Internet Engineering Task Force（IETF）定义的标准，它基于 SSL V3.0，并且在使用的加密算法上与其有些许的不同。例如，SSL 使用 Message Authentication Code（MAC）算法来生成完整性校验值，而 TLS 应用密钥的 Hashing for Message Authentication Code（HMAC）算法。
  
  
• IBM JSSE提供了SSL（Secure Sockets Layer）和TLS（Transport Layer Security）的java实现，在http://www-03.ibm.com/servers/eserver/zseries/software/java/jsse.html中可以得到详细的信息
  
  
• Keytool是一个管理密钥和证书的工具。关于它详细的使用信息可以在http://www.doc.ic.ac.uk/csg/java/1.3.1docs/tooldocs/solaris/keytool.html上得到
  
  
• HTTPClient的主页是http://jakarta.apache.org/commons/httpclient/，你可以在这里得到关于HttpClient更加详细的信息
  

自从接触Java和JSP以来，就不断与Java的中文乱码问题打交道，现在终于得到了彻底的解决，现将我们的解决心得与大家共享。

一、Java中文问题的由来

Java的内核和class文件是基于unicode的，这使Java程序具有良好的跨平台性，但也带来了一些中文乱码问题的麻烦。原因主要有两方面，Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。

首先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成class文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。基于这种乱码，建议在Java文件中尽量不要写中文（注释部分不参与编译，写中文没关系），如果必须写的话，尽量手动带参数－ecoding GBK或－ecoding gb2312编译；对于JSP，在文件头加上<%@ page contentType="text/html;charset=GBK"%>或<%@ page contentType="text/html;charset=gb2312"%>基本上就能解决这类乱码问题。

本文要重点讨论的是第二类乱码，即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介，如数据库，文件，流等的存储方式都是基于字节流的，Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换，具体情况如下：

从页面form提交数据到java程序 byte－>char
从java程序到页面显示 char—>byte

从数据库到java程序 byte—>char
从java程序到数据库 char—>byte

从文件到java程序 byte－>char
从java程序到文件 char－>byte

从流到java程序 byte－>char
从java程序到流 char－>byte

如果在以上转换过程中使用的编码方式与字节原有的编码不一致，很可能就会出现乱码。

二、解决方法

前面已经提到了Java程序与其他媒介交互时字符和字节的转换过程，如果这些转换过程中容易产生乱码。解决这些乱码问题的关键在于确保转换时使用的编码方式与字节原有的编码方式保持一致，下面分别论述（Java或JSP自身产生的乱码请参看第一部分）。

1、JSP与页面参数之间的乱码
JSP获取页面参数时一般采用系统默认的编码方式，如果页面参数的编码类型和系统默认的编码类型不一致，很可能就会出现乱码。解决这类乱码问题的基本方法是在页面获取参数之前，强制指定request获取参数的编码方式：request.setCharacterEncoding("GBK")或request.setCharacterEncoding("gb2312")。
如果在JSP将变量输出到页面时出现了乱码，可以通过设置response.setContentType("text/html;charset=GBK")或response.setContentType("text/html;charset=gb2312")解决。
如果不想在每个文件里都写这样两句话，更简洁的办法是使用Servlet规范中的过虑器指定编码，过滤器的在web.xml中的典型配置和主要代码如下：
web.xml:

<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>net.vschool.web.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

CharacterEncodingFilter.java:

public class CharacterEncodingFilter implements Filter
{

protected String encoding = null;

public void init(FilterConfig filterConfig) throws ServletException
{
this.encoding = filterConfig.getInitParameter("encoding");
}

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
chain.doFilter(request, response);
}

}

2、Java与数据库之间的乱码
大部分数据库都支持以unicode编码方式，所以解决Java与数据库之间的乱码问题比较明智的方式是直接使用unicode编码与数据库交互。很多数据库驱动自动支持unicode，如Microsoft的SQLServer驱动。其他大部分数据库驱动，可以在驱动的url参数中指定，如如mm的mysql驱动：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&characterEncoding=GBK。

3、Java与文件/流之间的乱码
Java读写文件最常用的类是FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream和FileOutputStream是基于字节流的，常用于读写二进制文件。读写字符文件建议使用基于字符的FileReader和FileWriter，省去了字节与字符之间的转换。但这两个类的构造函数默认使用系统的编码方式，如果文件内容与系统编码方式不一致，可能会出现乱码。在这种情况下，建议使用FileReader和FileWriter的父类：InputStreamReader/OutputStreamWriter，它们也是基于字符的，但在构造函数中可以指定编码类型：InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter(OutputStream out, Charset cs)。

4、其他
上面提到的方法应该能解决大部分乱码问题，如果在其他地方还出现乱码，可能需要手动修改代码。解决Java乱码问题的关键在于在字节与字符的转换过程中，你必须知道原来字节或转换后的字节的编码方式，转换时采用的编码必须与这个编码方式保持一致。我们以前使用Resin服务器，使用smartUpload组件上传文件，上传文件同时传递的中文参数获取没有乱码问题。当在Linux中把Resin设置成服务后，上传文件同时的中文参数获取出现了乱码。这个问题困扰了我们很久，后来我们分析smartUpload组件的源文件，因为文件上传采用的是字节流的方式，里面包含的参数名称和值也是字节流的方式传递的。smartUpload组件读取字节流后再将参数名称和值从字节流中解析出来，问题就出现在smartUpload将字节流转换成字符串时采用了系统默认的编码，而将Resin设置成服务后，系统默认的编码可能发生了改变，因此出现了乱码。后来，我们更改了smartUpload的源文件，增加了一个属性charset和setCharset(String)方法，将upload()方法中提取参数语句：
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1 );
改成了
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1, charset );
终于解决了这个乱码问题。

说明：
一个根元素：greeting；且这个元素不含属性，无子元素，内容是字符串。

hello.xsd
－－－－－－－－－－
<?xml version="1.0"?> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="greeting" type="xsd:string"/>
</xsd:schema>
说明：
XML Schema文档后缀名是.xsd，完全符合XML语法，根元素是schema，命名空间xmlns:xsd="http://www.w3.org/2001/XMLSchema，用元素<element>定义实例文档中的元素，如greeting。xsd:string就是定义的数据类型了，其中的数据类型有很多，比如：int,double,dateTime,Boolean,long,integer,float,等，总之Java等语言里有的数据类型它都有，但要以“xsd:”开头。
让我们再看一个里面有子无素的例子：
customer.xml
-----------
<customer>
<name>teiki</name>
<address>No.237, Road Waitan, Shanghai</address>
</customer>
则可以写出以下的XML Schema文档：
customer.xsd
----------------
1: <?xml version="1.0"?>
2: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3: <xsd:element name="customer">
4: <xsd:complexType>
5: <xsd:sequence>
6: <xsd:element name="name" type="xsd:string"/>
7: <xsd:element name="address" type="xsd:string" />
8: </xsd:sequence>
9: </xsd:complexType>
10: </xsd:element>
11: </xsd:schema>
说明：
实例文档customer.xml中，<customer>元素含有两个子元素，在Schema中凡是有两个以上的子元素，就认为是复杂类型的，所以我们在Schema文档中采用ComplexType来定义该元素。表示有多个XML子元素。
sequence表示子元素依次出现的顺序。
如果有多层子元素怎么办呢，同样的道理，有几层写几层，一直往下嵌就OK了，这里我要说的是另一种方法，结构看上去会清晰一些。
address.xml
---------------
<customer>
<name>Teiki</name>
<address>
<!-- address追加一个地址子元素 -->
<prefecture>Zhejiang</prefecture>
<city>Hangzhou</city>
<street>Xilu Road, No.121, 7F</street>
</address>
</customer>
下面就是采用ref元素来编写的这个Schema文档：
address2.xsd
----------------------
1: <?xm l version="1.0"?>
2: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3:
4: <xsd:element name="customer">
5: <xsd:complexType>
6: <xsd:sequence>
7: <xsd:element name="name" type="xsd:string"/>
8: <xsd:element ref="address"/>
9: </xsd:sequence>
10: </xsd:complexType>
11: </xsd:element>
12:
13: <xsd:element name="address">
14: <xsd:complexType>
15: <xsd:sequence>
16: <xsd:element name="prefecture" type="xsd:string"/>
17: <xsd:element name="city" type="xsd:string" />
18: <xsd:element name="street" type="xsd:string" />
19: </xsd:sequence>
20: </xsd:complexType>
21: </xsd:element>
22:
23: </xsd:schema>
说明：
如果按正常的写法，应该把13－21行的内容替换到每8行去，但这里使用ref元素可以直接将其指向另一个模块，使文档更加具有可读性。
如果元素中包含属性怎么办呢？一样简单，只要在定义完子元素的后面再着定义属性就行了。定义属性用“attribute”，还是举个例子吧
customer2.xml
---------------
<customer id="001718">
<name>Teiki</name>
<address>No.237, Road Waitan, Shanghai</address>
</customer>
这个例子和上面的一个例子差不多，只是在元素customer中设了一个属性id。
customer2.xsd
------------------
1: <?xml version="1.0"?>
2: <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3:
4: <xsd:element name="customer">
5: <xsd:complexType>
6: <xsd:sequence>
7: <xsd:element name="name" type="xsd:string"/>
8: <xsd:element name="address" type="xsd:string" />
9: </xsd:sequence>
10: <!-- 增加属性定义 -->
11: <xsd:attribute name="id" type="xsd:string"/>
12: </xsd:complexType>
13: </xsd:element>
14:
15: </xsd:schema>
说明：
需要注意的一点是，属性和元素不是一家的，所以要把它放在sequence外面写，但它们都在customer的孩子，所以要写在complexType的里面。
下面再看一个例子：
order4-1.xsd
----------------------
1:<?xml version="1.0"?>
2:<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
3:
4: <xsd:element name="order">
5: <xsd:complexType>
6: <xsd:sequence>
7: <xsd:element ref="orderItem" maxOccurs="10"/>
8: </xsd:sequence>
9: </xsd:complexType>
10: </xsd:element>
11:
12: <xsd:element name="orderItem">
13: <xsd:complexType>
14: <xsd:sequence>
15: <xsd:choice>
16: <xsd:element name="id" type="idType"/>
17: <xsd:element name="name" type="xsd:string"/>
18: </xsd:choice>
19: <xsd:element name="quantity" type="quantityType"/>
20: </xsd:sequence>
21: </xsd:complexType>
22: </xsd:element>
23: 
24: <xsd:simpleType name="idType">
25: <xsd:restriction base="xsd:string">
26: <xsd:enumeration value="7-5058-3496-7"/>
27: <xsd:enumeration value="7-5005-6450-3"/>
28: <xsd:enumeration value="7-3020-6069-7"/>
29: </xsd:restriction>
30: </xsd:simpleType>
31: 
32: <xsd:simpleType name="quantityType">
33: <xsd:restriction base="xsd:integer">
34: <xsd:minInclusive value="1"/>
35: <xsd:maxInclusive value="10"/>
36: </xsd:restriction>
37: </xsd:simpleType>
38:
39:</xsd:schema>
上面的例子中，maxOccurs代表:相同元素最多出现的次数,与些相反的是minOccurs代表：出现的最少次数。默认情况下两个都为“1”，如果把minOccurs设为“0”，表示该元素可有可无。choice代表：可选的元素，也就是在这里面写的元素只能选其中之一，不能全写。simpleType代表自定义数据类型，也就是name里的并不是真正的数据类型，而是根据自己的意愿定制的。restriction代表对某一数据类型做约束，也就是只能取其中范围之内符合要求的，比如第25－29行中，里面又有个元素enumeration代表枚举，也就是只能在枚举的那几个中选一个，而下在的36－36行，里面又有一对元素minInclusive和maxInclusive代表类型的取值范围，也就是只能取大于等于minInclusive并且小于等于maxInclusive的数。
把这个Schema用在XML中是这样的：
<?xml version="1.0" encoding="UTF-8"?>
<order xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="D:\ProgramCode\Year2\XML\practice\temp.xsd">
<orderItem>
<id>7-5005-6450-3</id>
<quantity>3</quantity>
</orderItem>
<orderItem>
<name>xyb</name>
<quantity>3</quantity>
</orderItem>
<!-- 注意下面这个是错的，因为超出了规定的范围 -->
<orderItem>
<id>7-5005-6450-3</id>
<quantity>13</quantity>
</orderItem>
<!? 从上面的注释到此，是错误的 -->
</order>
说明：
红色的部分是导入Schema的命令，绿色的是Schema文件的路径，如果用XMLSPY写时，会自动加上。
对属性的设置，基本上和元素的差不多。比如：
<xsd:element name="orderItem">
<xsd:complexType>
<xsd:sequence></xsd:sequence>
<xsd:attribute name="id" type="idType" use="required"/>
<xsd:attribute name="quantity" type="xsd:integer" default="1"/>
</xsd:complexType>
<xsd:simpleType name="idType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\d{1}-\d{4}-\d{4}-\d{1}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
这里我们讲id属性类型作为一种自定义数据类型idType。它的格式就是上面用到的也就是类似于“7-5005-6450-3”样的。
而且，用attribute元素的use属性来定义是否是必须的属性。
required是必须值，optional是可选值，prohibited是无属性值。default属性是默认值。

首先，我们写出一个最简单的XML文档.

hello.xml
-------------------
<?xml version="1.0"?> 
<greeting>Hello World!!</greeting>

（一个根元素：greeting；且这个元素不含属性，无子元素，内容是字符串。）

hello.xsd
－－－－－－－－－－
<?xml version="1.0"?> 
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="greeting" type="xsd:string"/>
</xsd:schema>

XML Schema文档后缀名是.xsd，完全符合XML语法，根元素是schema，命名空间xmlns:xsd="http://www.w3.org/2001/XMLSchema，用元素<element>定义实例文档中的元素，如greeting。

一、术语session

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

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

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

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

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

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

　　二、HTTP协议与状态保持

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

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

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

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

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

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

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

　　三、理解cookie机制

　　cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决：“会员卡”如何分发；“会员卡”的内容；以及客户如何使用“会员卡”。

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

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

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

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

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

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

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

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

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

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

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

　　使用Firefox可以很容易的观察现有的cookie的值

　　使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

　　IE也可以设置在接受cookie前询问

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

　　四、理解session机制

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

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

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

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

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

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

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

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

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

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

　　五、理解javax.servlet.http.HttpSession

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

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

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

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

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

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

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

　　六、HttpSession常见问题

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

　　1、session在何时被创建

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

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

　　2、session何时被删除

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

　　3、如何做到在浏览器关闭时删除session

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

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

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

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

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

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

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

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

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

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

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

　　10、为什么session不见了

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

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

　　七、跨应用程序的session共享

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

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

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

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

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

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

/NASApp

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

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

　　我们再看一下Weblogic Server是如何处理session的。

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

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

　　应用程序A

context.setAttribute("appA", session);

　　应用程序B

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

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

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

　　八、总结

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

public class ComponentClassLoader extends URLClassLoader {
  // ...

  public ComponentClassLoader (MasterClassLoader master, File file)
  {
    // ...
    JarFile jar = new JarFile(file);
    Manifest man = jar.getManifest();
    Attributes attr = man.getMainAttributes();

    List l = new ArrayList();
    String str = attr.getValue("Restricted-Class-Path");
    if (str != null) {
        StringTokenizer tok = new StringTokenizer(str);
        while (tok.hasMoreTokens()) {
            l.add(new File(file.getParentFile(),
                           tok.nextToken());
        }
    }

    this.dependencies = l;
  }

  public Class loadClass (String name, boolean resolve)
    throws ClassNotFoundException
  {
    try {
      // Try to load the class from our JAR.
      return loadClassForComponent(name, resolve);
    } catch (ClassNotFoundException ex) {}

    // Couldn't find it -- let the master look for it
    // in another components.
    return master.loadClassForComponent(name,
                           resolve, dependencies);
  }
    
  public Class loadClassForComponent (String name,
                                   boolean resolve)
    throws ClassNotFoundException
  {
    Class c = findLoadedClass(name);
    
    // Even if findLoadedClass returns a real class,
    // we might simply be its initiating ClassLoader.
    // Only return it if we're actually its defining
    // ClassLoader (as determined by Class.getClassLoader).
    //
    if (c == null || c.getClassLoader() != this) {
        c = findClass(name);
    
        if (resolve) {
            resolveClass(c);
        }
    }
    return c;
  }
}

public class MasterClassLoader extends ClassLoader {
  // ...

  public Class loadClassForComponent (String name,
                      boolean resolve, List files)
    throws ClassNotFoundException
  {
    try {
      return loadClass(name, resolve);
    } catch (ClassNotFoundException ex) {}

    for (Iterator i = files.iterator(); i.hasNext(); ) {
      File f = (File)i.next();

      try {
        ComponentClassLoader ccl =
            getComponentClassLoader(f);
        return ccl.loadClassForComponent(name, resolve);
      } catch (Exception ex) {
        // simplified for clarity
      }
    }

    throw new ClassNotFoundException(name);
  }
}

public static List initClassLoaders (MasterClassLoader master)
  throws MalformedURLException, IOException
{
  List loaders = new ArrayList();

  String classpath =
                System.getProperty("java.class.path");

  StringTokenizer tok = new StringTokenizer(classpath,
                                  File.pathSeparator);

  while (tok.hasMoreTokens()) {
    File file = new File(tok.nextToken());
    loaders.add(master.getComponentClassLoader(file));
  }

  return loaders;
}

 Log4j的配置
　　
　　以上是从原理方面说明Log4j的使用方法，在具体Java编程使用Log4j可以参照以下示例：
　　
　　1、 建立Logger实例：
　　语法表示：public static Logger getLogger( String name)
　　实际使用：static Logger logger = Logger.getLogger(ServerWithLog4j.class.getName ()) ;
　　
　　2、 读取配置文件：
　　获得了Logger的实例之后，接下来将配置Log4j使用环境：
　　语法表示：
　　BasicConfigurator.configure()：自动快速地使用缺省Log4j环境。
　　PropertyConfigurator.configure(String configFilename)：读取使用Java的特性文件编写的配置文件。
　　DOMConfigurator.configure(String filename)：读取XML形式的配置文件。
　　实际使用：
    PropertyConfigurator.configure("ServerWithLog4j.properties");
　　
　　3、 插入日志信息
　　完成了以上连个步骤以后，下面就可以按日志的不同级别插入到你要记录日志的任何地方了。
　　语法表示：
　　Logger.debug(Object message);//调试信息
　　Logger.info(Object message);//一般信息
　　Logger.warn(Object message);//警告信息
　　Logger.error(Object message);//错误信息
　　Logger.fatal(Object message);//致命错误信息

　　实际使用：logger.info("ServerSocket before accept: " + server);
　　
  配置过程

　在实际编程时，要使Log4j真正在系统中运行事先还要对配置文件进行定义。定义步骤就是对Logger、Appender及Layout的分别使用。
    Log4j支持两种配置文件格式，一种是XML格式的文件，一种是java properties（key=value）【Java特性文件（键=值）】。下面我们介绍使用Java特性文件做为配置文件的方法
   具体如下：
　　
　　1、配置根Logger，其语法为：
　　log4j.rootLogger = [ level ] , appenderName1, appenderName2, …
         level : 是日志记录的优先级，分为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。Log4j建议只使用四个级别，优先级从高到低分别是ERROR、WARN、INFO、DEBUG。通过在这里定义的级别，您可以控制到应用程序中相应级别的日志信息的开关。比如在这里定义了INFO级别，则应用程序中所有DEBUG级别的日志信息将不被打印出来。
　　     appenderName:就是指定日志信息输出到哪个地方。您可以同时指定多个输出目的地。
   例如：log4j.rootLogger＝info,A1,B2,C3
　　
　　2、配置日志信息输出目的地，其语法为：
　　log4j.appender.appenderName = fully.qualified.name.of.appender.class  //
　　  "fully.qualified.name.of.appender.class" 可以指定下面五个目的地中的一个：
          1.org.apache.log4j.ConsoleAppender（控制台）
          2.org.apache.log4j.FileAppender（文件）
          3.org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件）
          4.org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生一个新的文件）
          5.org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）
             1.ConsoleAppender选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    Target=System.err：默认情况下是：System.out,指定输出控制台
              2.FileAppender 选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    File=mylog.txt:指定消息输出到mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
            3.DailyRollingFileAppender 选项
                    Threshold=WARN:指定日志消息的输出最低层次。
                    ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                     File=mylog.txt:指定消息输出到 mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
                    DatePattern='.'yyyy-ww:每周滚动一次文件，即每周产生一个新的文件。当然也可以指定按月、周、天、时和分。即对应的格式如下：
                    1)'.'yyyy-MM: 每月
                    2)'.'yyyy-ww: 每周 
                    3)'.'yyyy-MM-dd: 每天
                    4)'.'yyyy-MM-dd-a: 每天两次
                    5)'.'yyyy-MM-dd-HH: 每小时
                    6)'.'yyyy-MM-dd-HH-mm: 每分钟
            4.RollingFileAppender 选项
                     Threshold=WARN:指定日志消息的输出最低层次。
                     ImmediateFlush=true:默认值是true,意谓着所有的消息都会被立即输出。
                    File=mylog.txt:指定消息输出到mylog.txt文件。
                    Append=false:默认值是true,即将消息增加到指定文件中，false指将消息覆盖指定的文件内容。
                    MaxFileSize=100KB: 后缀可以是KB, MB 或者是 GB. 在日志文件到达该大小时，将会自动滚动，即将原来的内容移到mylog.log.1文件。
                    MaxBackupIndex=2:指定可以产生的滚动文件的最大数。

实际应用：
　　log4j.appender.A1=org.apache.log4j.ConsoleAppender //这里指定了日志输出的第一个位置A1是控制台ConsoleAppender
　　
　　3、配置日志信息的格式，其语法为：
　　A.log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
              "fully.qualified.name.of.layout.class" 可以指定下面4个格式中的一个：
               1.org.apache.log4j.HTMLLayout（以HTML表格形式布局），
　　       2.org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
　　       3.org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
　　       4.org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）
                   1.HTMLLayout 选项
                      LocationInfo=true:默认值是false,输出java文件名称和行号
                      Title=my app file: 默认值是 Log4J Log Messages.
                   2.PatternLayout 选项
                      ConversionPattern=%m%n :指定怎样格式化指定的消息。
                   3.XMLLayout  选项
                      LocationInfo=true:默认值是false,输出java文件和行号
   实际应用：
   　　log4j.appender.A1.layout=org.apache.log4j.PatternLayout

       B. log4j.appender.A1.layout.ConversionPattern=%-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
           这里需要说明的就是日志信息格式中几个符号所代表的含义：
　　         －X号: X信息输出时左对齐；
                   %p: 输出日志信息优先级，即DEBUG，INFO，WARN，ERROR，FATAL,
                   %d: 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，比如：%d{yyy MMM dd HH:mm:ss,SSS}，输出类似：2002年10月18日 22：10：28，921
                   %r: 输出自应用启动到输出该log信息耗费的毫秒数
                   %c: 输出日志信息所属的类目，通常就是所在类的全名
                   %t: 输出产生该日志事件的线程名
                   %l: 输出日志事件的发生位置，相当于%C.%M(%F:%L)的组合,包括类目名、发生的线程，以及在代码中的行数。举例：Testlog4.main (TestLog4.java:10)
                   %x: 输出和当前线程相关联的NDC(嵌套诊断环境),尤其用到像java servlets这样的多客户多线程的应用中。
                   %%: 输出一个"%"字符
                   %F: 输出日志消息产生时所在的文件名称
                   %L: 输出代码中的行号
                   %m: 输出代码中指定的消息,产生的日志具体信息
                   %n: 输出一个回车换行符，Windows平台为"\r\n"，Unix平台为"\n"输出日志信息换行
            可以在%与模式字符之间加上修饰符来控制其最小宽度、最大宽度、和文本的对齐方式。如：
                     1)%20c：指定输出category的名称，最小的宽度是20，如果category的名称小于20的话，默认的情况下右对齐。
                     2)%-20c:指定输出category的名称，最小的宽度是20，如果category的名称小于20的话，"-"号指定左对齐。
                     3)%.30c:指定输出category的名称，最大的宽度是30，如果category的名称大于30的话，就会将左边多出的字符截掉，但小于30的话也不会有空格。
                     4)%20.30c:如果category的名称小于20就补空格，并且右对齐，如果其名称长于30字符，就从左边交远销出的字符截掉。

　　这里上面三个步骤是对前面Log4j组件说明的一个简化；下面给出一个具体配置例子，在程序中可以参照执行：
　　log4j.rootLogger=INFO,A1，B2
　　log4j.appender.A1=org.apache.log4j.ConsoleAppender
　　log4j.appender.A1.layout=org.apache.log4j.PatternLayout
　　log4j.appender.A1.layout.ConversionPattern=%-4r %-5p %d{yyyy-MM-dd HH:mm:ssS} %c %m%n
 　　根据上面的日志格式，某一个程序的输出结果如下：
　　0　　INFO　2003-06-13 13:23:46968 ClientWithLog4j Client socket: Socket[addr=localhost/127.0.0.1,port=8002,localport=2014]
         16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server says: 'Java server with log4j, Fri Jun 13 13:23:46 CST 2003'
　　16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j GOOD
　　16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Command 'HELLO' not understood.'
　　16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j HELP
　　16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j Server responds: 'Vocabulary: HELP QUIT'
　　16　 DEBUG 2003-06-13 13:23:46984 ClientWithLog4j QUIT
 
      4. # 当输出信息于回滚文件时

          log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender   //指定以文件的方式输出日志
           log4j.appender.ROLLING_FILE.Threshold=ERROR 
           log4j.appender.ROLLING_FILE.File=rolling.log  //文件位置,也可以用变量${java.home}、rolling.log
           log4j.appender.ROLLING_FILE.Append=true 
           log4j.appender.ROLLING_FILE.MaxFileSize=10KB  //文件最大尺寸
           log4j.appender.ROLLING_FILE.MaxBackupIndex=1  //备份数
           log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout 
           log4j.appender.ROLLING_FILE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n  　　

××××××××××××××××××××××××××××××××××××××××××××××××
 
 Log4j比较全面的配置

 LOG4J的配置之简单使它遍及于越来越多的应用中了：Log4J配置文件实现了输出到控制台、文件、回滚文件、发送日志邮件、输出到数据库日志表、自定义标签等全套功能。择其一二使用就够用了，

 log4j.rootLogger=DEBUG,CONSOLE,A1,im
 log4j.addivity.org.apache=true

 # 应用于控制台

 log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
 log4j.appender.Threshold=DEBUG
 log4j.appender.CONSOLE.Target=System.out
 log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
 log4j.appender.CONSOLE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n
 #log4j.appender.CONSOLE.layout.ConversionPattern=[start]%d{DATE}[DATE]%n%p[PRIORITY]%n%x[NDC]%n%t[THREAD] n%c[CATEGORY]%n%m[MESSAGE]%n%n

 #应用于文件

 log4j.appender.FILE=org.apache.log4j.FileAppender
 log4j.appender.FILE.File=file.log
 log4j.appender.FILE.Append=false
 log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
 log4j.appender.FILE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n
 # Use this layout for LogFactor 5 analysis

 # 应用于文件回滚

 log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender
 log4j.appender.ROLLING_FILE.Threshold=ERROR
 log4j.appender.ROLLING_FILE.File=rolling.log  //文件位置,也可以用变量${java.home}、rolling.log
 log4j.appender.ROLLING_FILE.Append=true       //true:添加  false:覆盖
 log4j.appender.ROLLING_FILE.MaxFileSize=10KB   //文件最大尺寸
 log4j.appender.ROLLING_FILE.MaxBackupIndex=1  //备份数
 log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout
 log4j.appender.ROLLING_FILE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n

 #应用于socket
 log4j.appender.SOCKET=org.apache.log4j.RollingFileAppender
 log4j.appender.SOCKET.RemoteHost=localhost
 log4j.appender.SOCKET.Port=5001
 log4j.appender.SOCKET.LocationInfo=true
 # Set up for Log Facter 5
 log4j.appender.SOCKET.layout=org.apache.log4j.PatternLayout
 log4j.appender.SOCET.layout.ConversionPattern=[start]%d{DATE}[DATE]%n%p[PRIORITY]%n%x[NDC]%n%t[THREAD]%n%c[CATEGORY]%n%m[MESSAGE]%n%n

 # Log Factor 5 Appender
 log4j.appender.LF5_APPENDER=org.apache.log4j.lf5.LF5Appender
 log4j.appender.LF5_APPENDER.MaxNumberOfRecords=2000

 # 发送日志给邮件

 log4j.appender.MAIL=org.apache.log4j.net.SMTPAppender
 log4j.appender.MAIL.Threshold=FATAL
 log4j.appender.MAIL.BufferSize=10
 log4j.appender.MAIL.From=web@www.wuset.com
 log4j.appender.MAIL.SMTPHost=www.wusetu.com
 log4j.appender.MAIL.Subject=Log4J Message
 log4j.appender.MAIL.To=web@www.wusetu.com
 log4j.appender.MAIL.layout=org.apache.log4j.PatternLayout
 log4j.appender.MAIL.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n

 # 用于数据库
 log4j.appender.DATABASE=org.apache.log4j.jdbc.JDBCAppender
 log4j.appender.DATABASE.URL=jdbc:mysql://localhost:3306/test
 log4j.appender.DATABASE.driver=com.mysql.jdbc.Driver
 log4j.appender.DATABASE.user=root
 log4j.appender.DATABASE.password=
 log4j.appender.DATABASE.sql=INSERT INTO LOG4J (Message) VALUES ('[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n')
 log4j.appender.DATABASE.layout=org.apache.log4j.PatternLayout
 log4j.appender.DATABASE.layout.ConversionPattern=[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n

 log4j.appender.A1=org.apache.log4j.DailyRollingFileAppender
 log4j.appender.A1.File=SampleMessages.log4j
 log4j.appender.A1.DatePattern=yyyyMMdd-HH'.log4j'
 log4j.appender.A1.layout=org.apache.log4j.xml.XMLLayout

 #自定义Appender

 log4j.appender.im = net.cybercorlin.util.logger.appender.IMAppender

 log4j.appender.im.host = mail.cybercorlin.net
 log4j.appender.im.username = username
 log4j.appender.im.password = password
 log4j.appender.im.recipient = corlin@cybercorlin.net

 log4j.appender.im.layout=org.apache.log4j.PatternLayout
 log4j.appender.im.layout.ConversionPattern =[framework] %d - %c -%-4r [%t] %-5p %c %x - %m%n

摘自:http://blog.csdn.net/eako/archive/2005/09/23/488099.aspx

静态库、动态连接库

程序编制一般需经编辑、编译、连接、加载和运行几个步骤。在我们的应用中，有一些公共代码是需要反复使用，就把这些代码编译为库文件；在连接步骤中，连接器将从库文件取得所需的代码，复制到生成的可执行文件中。这种库称为静态库，其特点是可执行文件中包含了库代码的一份完整拷贝；缺点就是被多次使用就会有多份冗余拷贝。

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

另外在当前的编程环境中，一般都提供方法让程序在运行的时候把某个特定的动态连接库加载并运行，也可以将其卸载（例如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就会在适当的时候把不会再使用的类卸载。