类加载器基本概念

顾名思义，类加载器（class loader）用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class 类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。

基本上所有的类加载器都是 java.lang.ClassLoader 类的一个实例。下面详细介绍这个 Java 类。

java.lang.ClassLoader 类介绍

java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等。不过本文只讨论其加载类的功能。为了完成加载类的这个职责，ClassLoader 提供了一系列的方法，比较重要的方法如 表 1 所示。关于这些方法的细节会在下面进行介绍。

对于 表 1 中给出的方法，表示类名称的 name 参数的值是类的二进制名称。需要注意的是内部类的表示，如 com.example.Sample$1 和 com.example.Sample$Inner 等表示方式。这些方法会在下面介绍类加载器的工作机制时，做进一步的说明。下面介绍类加载器的树状组织结构。

类加载器的树状组织结构

Java 中的类加载器大致可以分成两类，一类是系统提供的，另外一类则是由 Java 应用开发人员编写的。系统提供的类加载器主要有下面三个：

• 引导类加载器（bootstrap class loader）：它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
• 扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
• 系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader() 来获取它。

除了系统提供的类加载器以外，开发人员可以通过继承 java.lang.ClassLoader 类的方式实现自己的类加载器，以满足一些特殊的需求。

除了引导类加载器之外，所有的类加载器都有一个父类加载器。通过 表 1 中给出的 getParent() 方法可以得到。对于系统提供的类加载器来说，系统类加载器的父类加载器是扩展类加载器，而扩展类加载器的父类加载器是引导类加载器；对于开发人员编写的类加载器来说，其父类加载器是加载此类加载器 Java 类的类加载器。因为类加载器 Java 类如同其它的 Java 类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。图 1 中给出了一个典型的类加载器树状组织结构示意图，其中的箭头指向的是父类加载器。

代码清单 1 演示了类加载器的树状组织结构。

public class ClassLoaderTree { 

            

            public static void main(String[] args) { 

            ClassLoader loader = ClassLoaderTree.class.getClassLoader(); 

            while (loader != null) { 

            System.out.println(loader.toString()); 

            loader = loader.getParent(); 

            } 

            } 

            }

每个 Java 类都维护着一个指向定义它的类加载器的引用，通过 getClassLoader() 方法就可以获取到此引用。代码清单 1 中通过递归调用 getParent() 方法来输出全部的父类加载器。代码清单 1 的运行结果如 代码清单 2 所示。

sun.misc.Launcher$AppClassLoader@9304b1 

            sun.misc.Launcher$ExtClassLoader@190d11

如 代码清单 2 所示，第一个输出的是 ClassLoaderTree 类的类加载器，即系统类加载器。它是 sun.misc.Launcher$AppClassLoader 类的实例；第二个输出的是扩展类加载器，是 sun.misc.Launcher$ExtClassLoader 类的实例。需要注意的是这里并没有输出引导类加载器，这是由于有些 JDK 的实现对于父类加载器是引导类加载器的情况，getParent() 方法返回 null。

在了解了类加载器的树状组织结构之后，下面介绍类加载器的代理模式。

类加载器的代理模式

类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。在介绍代理模式背后的动机之前，首先需要说明一下 Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA 和 ClassLoaderB 分别读取了这个 Sample.class 文件，并定义出两个 java.lang.Class 类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。下面通过示例来具体说明。代码清单 3 中给出了 Java 类 com.example.Sample。

package com.example; 

            

            public class Sample { 

            private Sample instance; 

            

            public void setSample(Object instance) { 

            this.instance = (Sample) instance; 

            } 

            }

如 代码清单 3 所示，com.example.Sample 类的方法 setSample 接受一个 java.lang.Object 类型的参数，并且会把该参数强制转换成 com.example.Sample 类型。测试 Java 类是否相同的代码如 代码清单 4 所示。

public void testClassIdentity() { 

            String classDataRootPath = "C:\\workspace\\Classloader\\classData"; 

            FileSystemClassLoader fscl1 = new FileSystemClassLoader(classDataRootPath); 

            FileSystemClassLoader fscl2 = new FileSystemClassLoader(classDataRootPath); 

            String className = "com.example.Sample";  

            try { 

            Class<?> class1 = fscl1.loadClass(className); 

            Object obj1 = class1.newInstance(); 

            Class<?> class2 = fscl2.loadClass(className); 

            Object obj2 = class2.newInstance(); 

            Method setSampleMethod = class1.getMethod("setSample", java.lang.Object.class); 

            setSampleMethod.invoke(obj1, obj2); 

            } catch (Exception e) { 

            e.printStackTrace(); 

            } 

            }

代码清单 4 中使用了类 FileSystemClassLoader 的两个不同实例来分别加载类 com.example.Sample，得到了两个不同的 java.lang.Class 的实例，接着通过 newInstance() 方法分别生成了两个类的对象 obj1 和 obj2，最后通过 Java 的反射 API 在对象 obj1 上调用方法 setSample，试图把对象 obj2 赋值给 obj1 内部的 instance 对象。代码清单 4 的运行结果如 代码清单 5 所示。

java.lang.reflect.InvocationTargetException 

            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 

            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 

            at java.lang.reflect.Method.invoke(Method.java:597) 

            at classloader.ClassIdentity.testClassIdentity(ClassIdentity.java:26) 

            at classloader.ClassIdentity.main(ClassIdentity.java:9) 

            Caused by: java.lang.ClassCastException: com.example.Sample 

            cannot be cast to com.example.Sample 

            at com.example.Sample.setSample(Sample.java:7) 

            ... 6 more 

            

从 代码清单 5 给出的运行结果可以看到，运行时抛出了 java.lang.ClassCastException 异常。虽然两个对象 obj1 和 obj2 的类的名字相同，但是这两个类是由不同的类加载器实例来加载的，因此不被 Java 虚拟机认为是相同的。

了解了这一点之后，就可以理解代理模式的设计动机了。代理模式是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用 java.lang.Object 类，也就是说在运行的时候，java.lang.Object 这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object 类，而且这些类之间是不兼容的。通过代理模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。

不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到，后面会详细介绍。

下面具体介绍类加载器加载类的详细过程。

加载类的过程

在前面介绍类加载器的代理模式的时候，提到过类加载器会首先代理给其它类加载器来尝试加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类的加载工作是通过调用 defineClass 来实现的；而启动类的加载过程是通过调用 loadClass 来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。如类 com.example.Outer 引用了类 com.example.Inner，则由类 com.example.Outer 的定义加载器负责启动类 com.example.Inner 的加载过程。

方法 loadClass() 抛出的是 java.lang.ClassNotFoundException 异常；方法 defineClass() 抛出的是 java.lang.NoClassDefFoundError 异常。

类加载器在成功加载某个类之后，会把得到的 java.lang.Class 类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器实例来说，相同全名的类只加载一次，即 loadClass 方法不会被重复调用。

下面讨论另外一种类加载器：线程上下文类加载器。

线程上下文类加载器

线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。类 java.lang.Thread 中的方法 getContextClassLoader() 和 setContextClassLoader(ClassLoader cl) 用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl) 方法进行设置的话，线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。

前面提到的类加载器的代理模式并不能解决 Java 应用开发中会遇到的类加载器的全部问题。Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers 包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来，可以通过类路径（CLASSPATH）来找到，如实现了 JAXP SPI 的 Apache Xerces 所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory 类中的 newInstance() 方法用来生成一个新的 DocumentBuilderFactory 的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的实现所提供的。如在 Apache Xerces 中，实现的类是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。

线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。

下面介绍另外一种加载类的方法：Class.forName。

Class.forName

Class.forName 是一个静态方法，同样可以用来加载类。该方法有两种形式：Class.forName(String name, boolean initialize, ClassLoader loader) 和 Class.forName(String className)。第一种形式的参数 name 表示的是类的全名；initialize 表示是否初始化类；loader 表示加载时使用的类加载器。第二种形式则相当于设置了参数 initialize 的值为 true，loader 的值为当前类的类加载器。Class.forName 的一个很常见的用法是在加载数据库驱动的时候。如 Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance() 用来加载 Apache Derby 数据库的驱动。

在介绍完类加载器相关的基本概念之后，下面介绍如何开发自己的类加载器。

回页首

开发自己的类加载器

虽然在绝大多数情况下，系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下，您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输 Java 类的字节代码，为了保证安全性，这些字节代码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最后定义出要在 Java 虚拟机中运行的类来。下面将通过两个具体的实例来说明类加载器的开发。

文件系统类加载器

第一个类加载器用来加载存储在文件系统上的 Java 字节代码。完整的实现如 代码清单 6 所示。

public class FileSystemClassLoader extends ClassLoader { 

            

            private String rootDir; 

            

            public FileSystemClassLoader(String rootDir) { 

            this.rootDir = rootDir; 

            } 

            

            protected Class<?> findClass(String name) throws ClassNotFoundException { 

            byte[] classData = getClassData(name); 

            if (classData == null) { 

            throw new ClassNotFoundException(); 

            } 

            else { 

            return defineClass(name, classData, 0, classData.length); 

            } 

            } 

            

            private byte[] getClassData(String className) { 

            String path = classNameToPath(className); 

            try { 

            InputStream ins = new FileInputStream(path); 

            ByteArrayOutputStream baos = new ByteArrayOutputStream(); 

            int bufferSize = 4096; 

            byte[] buffer = new byte[bufferSize]; 

            int bytesNumRead = 0; 

            while ((bytesNumRead = ins.read(buffer)) != -1) { 

            baos.write(buffer, 0, bytesNumRead); 

            } 

            return baos.toByteArray(); 

            } catch (IOException e) { 

            e.printStackTrace(); 

            } 

            return null; 

            } 

            

            private String classNameToPath(String className) { 

            return rootDir + File.separatorChar 

            + className.replace('.', File.separatorChar) + ".class"; 

            } 

            }

如 代码清单 6 所示，类 FileSystemClassLoader 继承自类 java.lang.ClassLoader。在 表 1 中列出的 java.lang.ClassLoader 类的常用方法中，一般来说，自己开发的类加载器只需要覆写 findClass(String name) 方法即可。java.lang.ClassLoader 类的方法 loadClass() 封装了前面提到的代理模式的实现。该方法会首先调用 findLoadedClass() 方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的 loadClass() 方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用 findClass() 方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写 loadClass() 方法，而是覆写 findClass() 方法。

类 FileSystemClassLoader 的 findClass() 方法首先根据类的全名在硬盘上查找类的字节代码文件（.class 文件），然后读取该文件内容，最后通过 defineClass() 方法来把这些字节代码转换成 java.lang.Class 类的实例。

网络类加载器

下面将通过一个网络类加载器来说明如何通过类加载器来实现组件的动态更新。即基本的场景是：Java 字节代码（.class）文件存放在服务器上，客户端通过网络的方式获取字节代码并执行。当有版本更新的时候，只需要替换掉服务器上保存的文件即可。通过类加载器可以比较简单的实现这种需求。

类 NetworkClassLoader 负责通过网络下载 Java 类字节代码并定义出 Java 类。它的实现与 FileSystemClassLoader 类似。在通过 NetworkClassLoader 加载了某个版本的类之后，一般有两种做法来使用它。第一种做法是使用 Java 反射 API。另外一种做法是使用接口。需要注意的是，并不能直接在客户端代码中引用从服务器上下载的类，因为客户端代码的类加载器找不到这些类。使用 Java 反射 API 可以直接调用 Java 类的方法。而使用接口的做法则是把接口的类放在客户端中，从服务器上加载实现此接口的不同版本的类。在客户端通过相同的接口来使用这些实现类。网络类加载器的具体代码见 下载。

在介绍完如何开发自己的类加载器之后，下面说明类加载器和 Web 容器的关系。


类加载器与 Web 容器

对于运行在 Java EE™ 容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。

绝大多数情况下，Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则：

• 每个 Web 应用自己的 Java 类文件和使用的库的 jar 包，分别放在 WEB-INF/classes 和 WEB-INF/lib 目录下面。
• 多个应用共享的 Java 类文件和 jar 包，分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
• 当出现找不到类的错误时，检查当前类的类加载器和当前线程的上下文类加载器是否正确。

在介绍完类加载器与 Web 容器的关系之后，下面介绍它与 OSGi 的关系。

类加载器与 OSGi

OSGi™ 是 Java 上的动态模块系统。它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式用来管理软件的生命周期。OSGi 已经被实现和部署在很多产品上，在开源社区也得到了广泛的支持。Eclipse 就是基于 OSGi 技术来构建的。

OSGi 中的每个模块（bundle）都包含 Java 包和类。模块可以声明它所依赖的需要导入（import）的其它模块的 Java 包和类（通过 Import-Package），也可以声明导出（export）自己的包和类，供其它模块使用（通过 Export-Package）。也就是说需要能够隐藏和共享一个模块中的某些 Java 包和类。这是通过 OSGi 特有的类加载器机制来实现的。OSGi 中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的 Java 包和类。当它需要加载 Java 核心库的类时（以 java 开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的 Java 类时，它会代理给导出此 Java 类的模块来完成加载。模块也可以显式的声明某些 Java 包和类，必须由父类加载器来加载。只需要设置系统属性 org.osgi.framework.bootdelegation 的值即可。

假设有两个模块 bundleA 和 bundleB，它们都有自己对应的类加载器 classLoaderA 和 classLoaderB。在 bundleA 中包含类 com.bundleA.Sample，并且该类被声明为导出的，也就是说可以被其它模块所使用的。bundleB 声明了导入 bundleA 提供的类 com.bundleA.Sample，并包含一个类 com.bundleB.NewSample 继承自 com.bundleA.Sample。在 bundleB 启动的时候，其类加载器 classLoaderB 需要加载类 com.bundleB.NewSample，进而需要加载类 com.bundleA.Sample。由于 bundleB 声明了类 com.bundleA.Sample 是导入的，classLoaderB 把加载类 com.bundleA.Sample 的工作代理给导出该类的 bundleA 的类加载器 classLoaderA。classLoaderA 在其模块内部查找类 com.bundleA.Sample 并定义它，所得到的类 com.bundleA.Sample 实例就可以被所有声明导入了此类的模块使用。对于以 java 开头的类，都是由父类加载器来加载的。如果声明了系统属性 org.osgi.framework.bootdelegation=com.example.core.*，那么对于包 com.example.core 中的类，都是由父类加载器来完成的。

OSGi 模块的这种类加载器结构，使得一个类的不同版本可以共存在 Java 虚拟机中，带来了很大的灵活性。不过它的这种不同，也会给开发人员带来一些麻烦，尤其当模块需要使用第三方提供的库的时候。下面提供几条比较好的建议：

• 如果一个类库只有一个模块使用，把该类库的 jar 包放在模块中，在 Bundle-ClassPath 中指明即可。
• 如果一个类库被多个模块共用，可以为这个类库单独的创建一个模块，把其它模块需要用到的 Java 包声明为导出的。其它模块声明导入这些类。
• 如果类库提供了 SPI 接口，并且利用线程上下文类加载器来加载 SPI 实现的 Java 类，有可能会找不到 Java 类。如果出现了 NoClassDefFoundError 异常，首先检查当前线程的上下文类加载器是否正确。通过 Thread.currentThread().getContextClassLoader() 就可以得到该类加载器。该类加载器应该是该模块对应的类加载器。如果不是的话，可以首先通过 class.getClassLoader() 来得到模块对应的类加载器，再通过 Thread.currentThread().setContextClassLoader() 来设置当前线程的上下文类加载器。

总结

类加载器是 Java 语言的一个创新。它使得动态安装和更新软件组件成为可能。本文详细介绍了类加载器的相关话题，包括基本概念、代理模式、线程上下文类加载器、与 Web 容器和 OSGi 的关系等。开发人员在遇到 ClassNotFoundException 和 NoClassDefFoundError 等异常的时候，应该检查抛出异常的类的类加载器和当前线程的上下文类加载器，从中可以发现问题的所在。在开发自己的类加载器的时候，需要注意与已有的类加载器组织结构的协调。

来自：http://www.pussor.com/?p=3

官网：http://www.pushlets.com/

Ajax等Web 2.0技术的广泛应用，推动了C/S向B/S的转变，如今很多应用如监控、即时通信等系统都需要实时同步服务器端和客户端的数据更新。Comet在这种需求下应运而生，本文简单介绍了基于Comet的开源框架Pushlet。

Comet基础

Comet 是一个用于描述客户端和服务器之间的交互的术语，即使用长期保持的 HTTP 连接来在连接保持畅通的情况下支持客户端和服务器间的事件驱动的通信。

—引用自“Comet的诱惑”

传统的web系统的工作流程是客户端发出请求，服务器端进行响应，而Comet则是在现有技术的基础上，实现服务器数据、事件等快速PUSH到客户端，所以会出现一个术语”服务器推“技术。

PUSH实现方式

JSP/SERVLET PUSH

原理：

利用JSP/SERVEL技术，在不关闭HTTP流的情况下PUSH数据到客户端浏览器；

实现：

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

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

1. 服务器端会阻塞请求直到有数据传递或超时才返回。
2. 客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。
3. 当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重 新建立连接，客户端会一次把当前服务器端所有的信息取回。

Pushlet实例

以Pushlet中的ping案例来进行分析：

1. 新建一个Web项目取名ping，并导入Pushlet的jar包；
2. 在src目录下配置sources.properties、pushlet.properties文件;
3. webroot目录下导入js-pushlet-client.js，js-pushlet-net.html；
4. 新建TestEventPullSources.java；
5. 新建index.html,引入js-pushlet-client.js；
6. 新建pingok.jsp；
7. 修改web.xml加上pushlet的servlet
8. 打包、部署ping项目;

实例1            Pushlet CookBook部分翻译 + 注释

pushlet 2.0.3 源码分析(服务器端)

 这里以tomcat环境为例，其它WEB服务器如jboss,weblogic等是同一个道理。

 一、java.lang.OutOfMemoryError: PermGen space PermGen space的全称是Permanent Generation space,是指内存的永久保存区域, 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中, 它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对 PermGen space进行清理，所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误, 这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。

 解决方法： 手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行： JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m

 建议：将相同的第三方jar文件移置到tomcat/shared/lib目录下，这样可以达到减少jar 文档重复占用内存的目的。

 二、java.lang.OutOfMemoryError: Java heap space Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

 解决方法：手动设置Heap size 修改TOMCAT_HOME/bin/catalina.sh 在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行： JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

 三、实例，以下给出1G内存环境下java jvm 的参数设置参考：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "

内存不足 (OutOfMemory) － 由于java 堆或本地内存中的内存耗尽，应用程序显示“内存不足”错误。
内存泄漏－java 堆或本地内存的持续内存增长，最终将导致内存不足状态。
调试内存泄漏状态的技术与调试内存不足状态的技术相同。

Java 堆 － 这是 JVM 用来分配 java 对象的内存。
如果JVM不能在java堆中获得更多内存来分配更多java对象，将会抛出java内存不足(java.lang.OutOfMemoryError)错误。默认情况下，应用程序崩溃。
本地内存 － 这是 JVM 用于其内部操作的内存。
如果 JVM 无法获得更多本地内存，它将抛出本地内存不足（本地 OutOfMemoryError）错误。当进程到达操作系统的进程大小限值，或者当计算机用完 RAM 和交换空间时，通常会发生这种情况。
进程大小 － 进程大小将是 java 堆、本地内存与加载的可执行文件和库所占用内存的总和。在 32 位操作系统上，进程的虚拟地址空间最大可达到 4 GB。从这 4 GB 内存中，操作系统内核为自己保留一部分内存（通常为 1 - 2 GB）。剩余内存可用于应用程序。

2.
java虚拟机是遵照有关规范的一个软件实现，存在于内存中。jvm是由安装于机器上的jre(java运行环境)生成的。通常来说，每次运行一个application都会生成一个jvm，但是也可以有多个程序在同一个jvm里面。

可以使用命令java -X查看非标准(non-standard)的程序运行选项，以下3个是我所关心的：

-Xms        set initial Java heap size
-Xmx        set maximum Java heap size
-Xss        set java thread stack size

－Xmx设置应用程序(不是jvm)能够使用的最大内存数，这个值也不应该设置过大，超过机器内存。
例如：java -Xmx50M testMemory
－Xms设置程序初始化的时候内存栈的大小。有时可以用于改变程序运行的效率。
例如使用以下方式运行一个占用20M左右内存的程序testMemory：
      java -Xms50M testMemory

使用这个方法可以得到应用的空间使用量

/**//*
Returns the total amount of memory in the Java virtual machine. The value returned by this method may vary over time, depending on the host environment.
*/
System.out.println(Runtime.getRuntime().totalMemory());

3.
查看java进程的内存使用量：
Windows任务管理器(Windows Task Manager)

增大运行应用的Heap的取值

//命令行执行方式
java -Xms256 -Xmx512m app

//Tomcat执行方式
Windows下，在文件{tomcat_home}/bin/catalina.bat

在文件开头可增加如下设置：

set JAVA_OPTS=-Xms256m -Xmx512m

Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，可增加如下设置：

JAVA_OPTS='-Xms256m -Xmx512m'

1 配置Action的struts.xml 􁭛􀓊􀇄

<struts>
    <!-- Struts 2的Action都必须配置在package里-->
    <package name="default" extends="struts-default">
<!-- 定义一个Logon的Action实现类为lee.Logon -->
<action name="Logon" class="lee.Logon">
<!--配置Action返回input时转入/pages/Logon.jsp页面-->
<result name="input">/pages/Logon.jsp</result>
<!--配置Action返回cancel时重定向到Welcome的Action-->
<result name="cancel" type="redirect-action">Welcome</result>
<!--配置Action返回success时重定向到MainMenu的Action -->
<result type="redirect-action">MainMenu</result>
<!--配置Action返回expired时进入ChangePassword的Action连-->
<result name="expired" type="chain">ChangePassword</result>
</action>
<!--定义Logoff的Action实现类为lee.Logoff -->
<action name="Logoff" class=" lee.Logoff">
<!--配置Action返回success重定向到MainMenu的Action -->
<result type="redirect-action">Welcome</result>
</action>
</package>
</struts>

#指定Struts 2处于开发状态 􀻘􀑢􁓔􀦥􂢊􁗕
struts.devMode = false
#指定当Struts 2配置文件改变后，Web框架是否重新加载Struts 2配置文件 􄜡􃕂􁭛􀓊
struts.configuration.xml.reload=true

<?xml version="1.0" encoding="GBK"?>
<!-- web-app是Web应用配置文件的根元素，提定Web应用的Schema信息-->
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.
com/xml/ns/j2ee/web-app_2_4.xsd">
<!--定义Struts 2的FilterDispatcher的Filter -->
<filter>
<!-- 定义核心Filter的名字-->
<filter-name>struts2</filter-name>
<!--典定义核心Filter的实现类 -->
<filter-class>org.apache.Struts2.dispatcher.FilterDispatcher
</ filter-class>
<init-param>
<!--配置Struts 2框架默认加载的Action包结构-->
<param-name>actionPackages</param-name>
<param-value>org.apache.struts2.showcase.person</param-value>
</init-param>
<!--配置Struts 2框架的配置提共者类-->
<init-param>
<param-name>configProviders </param-name>
<param-value>lee.MyConfigurationProvider</param-value>
</init-param>
</filter>
<!-- FilterDispatcher用来初始化Struts 2并且处理所有的Web请求-->
<filter-mapping>
<filter-name>Struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>

<!--手动配置Struts 2的标签库-->
<taglib>
<!--配置Struts 2标签库的URI -->
<taglib-uri>/s</taglib-uri>
<!--指定Struts 2标签库定义文件的位置-->
<taglib-location>/WEB-INF/struts-tags.tld</taglib-location>
</taglib>

<?xml version="1.0" encoding="UTF-8" ?>
<!-- 指定Struts 2 配置文件的DTD信息-->
<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"
"http://struts.apache.org/dtds/struts-2.0.dtd">
<!--下面是Struts 2配置文件的根元素-->
<struts>
<!--通过include元素导入其他配置文件-->
<include file="struts-part1.xml" />

</struts>

<!--指定Struts 2 配置文件的根元素 -->
<struts>
<!-- 配置名为lee的包空间，继承struts-default包空间-->
<package name="lee" extends="struts-default">

</package>
</struts>

方法一：
 conf/server.xml文件
 Context path中间加上reloadable="true"
 例如：<Context path="" docBase=""  reloadable="true">

方法二：
 删除work目录下的缓存文件
 可以把Catalina目录删除；
 
 注意：不能把work整个目录删除，不然重启tomcat时，会把conf/web.xml删除掉，这样在启动时，日志会提示：No Default web.xml，且访问页面会显示404错误；

什么是JNDI？为什么使用JNDI？

JNDI是Java 命名与目录接口（Java Naming and Directory Interface）

要了解JNDI的作用，我们可以从“如果不用JNDI我们怎样做？用了JNDI后我们又将怎样做？”这个问题来探讨。

没有JNDI的做法：
程序员开发时，知道要开发访问MySQL数据库的应用，于是将一个对 MySQL JDBC 驱动程序类的引用进行了编码，并通过使用适当的 JDBC URL 连接到数据库。
就像以下代码这样：

Connection conn=null;
try {
   Class.forName("com.mysql.jdbc.Driver",true, Thread.currentThread().getContextClassLoader());        conn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=qingfeng&password=mingyue");  /* 使用conn并进行SQL操作 */     conn.close();
} catch(Exception e) {
   e.printStackTrace();
} finally {
   if(conn!=null) {
    try {       conn.close();   
    } catch(SQLException e) {
    }
}}
这是传统的做法，这种做法一般在小规模的开发过程中不会产生问题，只要程序员熟悉Java语言、了解JDBC技术和MySQL，可以很快开发出相应的应用程序。

没有JNDI的做法存在的问题：
1、数据库服务器名称MyDBServer 、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；
2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；
3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；
4、......

解决办法：
程序员应该不需要关心“具体的数据库后台是什么？JDBC驱动程序是什么？JDBC URL格式是什么？访问数据库的用户名和口令是什么？”等等这些问题，程序员编写的程序应该没有对 JDBC 驱动程序的引用，没有服务器名称，没有用户名称或口令 —— 甚至没有数据库池或连接管理。而是把这些问题交给J2EE容器来配置和管理，程序员只需要对这些配置和管理进行引用即可。

由此，就有了JNDI。

用了JNDI之后的做法：
首先，在在J2EE容器中配置JNDI参数，定义一个数据源，也就是JDBC引用参数，给这个数据源设置一个名称；然后，在程序中，通过数据源名称引用数据源从而访问后台数据库。
具体操作如下（以JBoss为例）：
1、配置数据源
在JBoss的 D:\jboss420GA\docs\examples\jca 文件夹下面，有很多不同数据库引用的数据源定义模板。将其中的 mysql-ds.xml 文件Copy到你使用的服务器下，如 D:\jboss420GA\server\default\deploy。
修改 mysql-ds.xml 文件的内容，使之能通过JDBC正确访问你的MySQL数据库，如下：
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
    <jndi-name>MySqlDS</jndi-name>
    <connection-url>jdbc:mysql://localhost:3306/lw</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>root</user-name>
    <password>rootpassword</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
</local-tx-datasource>
</datasources>

这里，定义了一个名为MySqlDS的数据源，其参数包括JDBC的URL，驱动类名，用户名及密码等。

2、在程序中引用数据源：

Connection conn=null;
try { 
Context ctx=new InitialContext();
Object datasourceRef=ctx.lookup("java:MySqlDS"); //引用数据源 
DataSource ds=(Datasource)datasourceRef;  conn=ds.getConnection();  /* 使用conn进行数据库SQL操作 */
...... 
c.close();
} catch(Exception e) { 
e.printStackTrace();
} finally {  if(conn!=null) {   
 try {    
 conn.close();   
 } catch(SQLException e) { }  }}
直接使用JDBC或者通过JNDI引用数据源的编程代码量相差无几，但是现在的程序可以不用关心具体JDBC参数了。
在系统部署后，如果数据库的相关参数变更，只需要重新配置 mysql-ds.xml 修改其中的JDBC参数，只要保证数据源的名称不变，那么程序源代码就无需修改。

由此可见，JNDI避免了程序与数据库之间的紧耦合，使应用更加易于配置、易于部署。

所以，在J2EE规范中，J2EE 中的资源并不局限于 JDBC 数据源。引用的类型有很多，其中包括资源引用（已经讨论过）、环境实体和 EJB 引用。特别是 EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一项关键角色：查找其他应用程序组件。

JNDI原理

sun只是提供了JNDI的接口(即规范),IBM, Novell, Sun 和 WebLogic 和JBOSS已经为 JNDI 提供了服务提供程序,

在JNDI中，在目录结构中的每一个结点称为context。每一个JNDI名字都是相对于context的。这里没有绝对名字的概念存在。对一个应用来说，它可以通过使用 InitialContext 类来得到其第一个context: 

    Context ctx = new InitialContext();

    ctx.bind("name", Object);

    ctx.lookup("name");

Context:上下文,我的理解是相当与文件系统的中的目录(JNDI的Naming Service是可以用操作系统的文件系统的,哈哈).

entry/object:一个节点,相当与文件系统中的目录或文件.

filter:查询/过滤条件是一个字符串表达式如:(&(objectClass=top)(cn=*))查询出objectClass属性为top,cn属性为所有情况的entry.

Attribute:entry/object的属性可以理解成JAVA对象的属性,不同的是这个属性可以多次赋值.

A.将接口分为Context 和 DirContext  

   JNDI有两个核心接口Context和DirContext，Context中包含 了基本的名字操作，而DirContext则将这些操作扩展到目录服务。DirContext 对Context进行了扩展，提供了基本的目录服务操作， 对名字对象属性的维护、基于属性的名字查找等等。  

B.上下文列表的多种方法  

   一般来说有两种进行上下文列表的应用：上下文浏览应用和对上下文中的对象进行实际操作的应用。  

   上下文浏览应用一般只需要显示上下文中包含内容的名字，或者再获取一些诸如对象的类型之类的信息。这种类型的应用一般都是交互式的，可以允许用户在列举的上下文列表中选择一些进行进一步的显示。  

   另外有一些应用需要对上下文中的对象进行实际的操作，比如，一个备份程序需要对目录中所有文件的状态进行操作，或者某打印机管理员可能需要对大楼中的所有打印机进行复位。为了进行这样的操作，程序需要获取上下文中的实际对象。  

   对于这样两种类型的应用，Context接口提供了两种上下文列表方法list()和 listBindings()。其中list()只返回一系列名字/类映射，而listBindings() 则返回名字、类和对象本身。显然 list()用于上下文浏览应用而listBindings()用于那些需要对对象进行实际操作的应用。  
例:
=================将以下代码段添加到server.xml中的<Host>中============
<!-- configure DataSource. Add the following code into server.xml -->

<Context path="/bookstore" docBase="bookstore" debug="0"
reloadable="true" >

<!-- 数据源名称 -->
<Resource name="jdbc/BookDB"
               auth="Container"
               type="javax.sql.DataSource" />

<ResourceParams name="jdbc/BookDB">
    <parameter>
      <name>factory</name>
      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
    </parameter>

    <!-- Maximum number of dB connections in pool. Make sure you
         configure your mysqld max_connections large enough to handle
         all of your db connections. Set to 0 for no limit.
         -->
<!-- 活动状态最大连接数 -->
    <parameter>
      <name>maxActive</name>
      <value>100</value>
    </parameter>

    <!-- Maximum number of idle dB connections to retain in pool.
         Set to 0 for no limit.
         -->
<!-- 空闲状态数据库连接最大数 -->
    <parameter>
      <name>maxIdle</name>
      <value>30</value>
    </parameter>

    <!-- Maximum time to wait for a dB connection to become available
         in ms, in this example 10 seconds. An Exception is thrown if
         this timeout is exceeded. Set to -1 to wait indefinitely.
        Maximum time to wait for a dB connection to become available
         in ms, in this example 10 seconds. An Exception is thrown if
         this timeout is exceeded. Set to -1 to wait indefinitely.
         -->
<!-- 数据库处于空闲状态的最长时间 -->
    <parameter>
      <name>maxWait</name>
      <value>10000</value>
    </parameter>

    <!-- MySQL dB username and password for dB connections -->
<!-- 指定连接数据库的用户名及密码 -->
    <parameter>
     <name>username</name>
     <value>dbuser</value>
    </parameter>
    <parameter>
     <name>password</name>
     <value>1234</value>
    </parameter>

    <!-- Class name for mm.mysql JDBC driver -->
<!-- 指定JDBC驱动 -->
    <parameter>
       <name>driverClassName</name>
       <value>com.mysql.jdbc.Driver</value>
    </parameter>

    <!-- The JDBC connection url for connecting to your MySQL dB.
         The autoReconnect=true argument to the url makes sure that the
         mm.mysql JDBC Driver will automatically reconnect if mysqld closed the
         connection. mysqld by default closes idle connections after 8 hours.
         -->
<!-- 指定连接数据库的URL -->
    <parameter>
      <name>url</name>
      <value>jdbc:mysql://localhost:3306/BookDB?autoReconnect=true</value>
    </parameter>
</ResourceParams>

</Context> 
运行机制：
1、 首先程序代码获取初始化的 JNDI 环境并且调用 Context.lookup() 方法从 JNDI 服务提供者那里获一个 DataSource 对象

2、 中间层 JNDI 服务提供者返回一个 DataSource 对象给当前的 Java 应用程序这个 DataSource 对象代表了中间层服务上现存的缓冲数据源

3、 应用程序调用 DataSource 对象的 getConnection() 方法

4、 当 DataSource 对象的 getConnection() 方法被调用时，中间层服务器将查询数据库 连接缓冲池中有没有 PooledConnection 接口的实例对象。这个 PooledConnection 对象将被用于与数据库建立物理上的数据库连接

5、 如果在缓冲池中命中了一个 PooledCoonection 对象那么连接缓冲池将简单地更 新内部的缓冲连接队列并将该 PooledConnection 对象返回。如果在缓冲池内没 有找到现成的 PooledConnection 对象，那么 ConnectionPoolDataSource 接口将会被 用来产生一个新的 PooledConnection 对象并将它返回以便应用程序使用

6。 中间层服务器调用 PooledConnection 对象的 getConnection() 方法以便返还一个 java.sql.Connection 对象给当前的 Java 应用程序

7、 当中间层服务器调用 PooledConnection 对象的 getConnection() 方法时， JDBC 数据 库驱动程序将会创建一个 Connection 对象并且把它返回中间层服务器

8、 中间层服务器将 Connection 对象返回给应用程序 Java 应用程序，可以认为这个 Connection 对象是一个普通的 JDBC Connection 对象使用它可以和数据库建立。事 实上的连接与数据库引擎产生交互操作 。

9、 当应用程序不需要使用 Connection 对象时，可以调用 Connection 接口的 close() 方 法。请注意这种情况下 close() 方法并没有关闭事实上的数据库连接，仅仅是释 放了被应用程序占用的数据库连接，并将它还给数据库连接缓冲池，数据库连接 缓冲池会自动将这个数据库连接交给请求队列中下一个的应用程序使用。

JDBC-ODBC桥连接数据库

不足：需要在客户端安装ODBC驱动程序,ODBC驱动程序还需要具有客户端的控制权限。
方法：
1.创建数据源
2.装载驱动并与DBMS建立连接
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");     
Connection con=DriverManager.getConnectio("jdbc:odbc:jia","sa","123");
3.查询   
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stmt.executeQuery(sql);   
4.更新   
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_READ_ONLY);         
if(stmt.executeUpdate(sql)<=0){return false;}   
else{return true;}      
5.读取数据
Statement 接口提供了3种执行SQL语句的方法：
qexecuteQuery()
qexecuteUpdate()
qexecute()
6.tTransaction     
Connection con=DriverManager.getConnectio("jdbc:odbc:jia","sa","123");
con.setAutoCommit(false);//关闭自动提交模式
Statement stmt = con.createStatement();   
stmt.qexecute(sql);   
stmt.qexecute(sql);   
stmt.qexecute(sql);     
con.commit();           //提交 
con.setAutoCommit(true);//开启自动提交模式
con.rollback();         //回滚
7.关闭连接对象
con.close();
con.isClosed();

JDBC连接数据库

方法:
1.Oracle8/8i/9i数据库（thin模式）
Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
String url="jdbc:oracle:thin:@localhost:1521:orcl"; //orcl为数据库SID
String user="test";
String password="test";
Connection conn= DriverManager.getConnection(url,user,password); 
2.DB2数据库
Class.forName("com.ibm.db2.jdbc.app.DB2Driver ").newInstance();
String url="jdbc:db2://localhost:5000/sample"; //sample为你的数据库名
String user="admin";
String password="";
Connection conn= DriverManager.getConnection(url,user,password); 
3.Sql Server7.0/2000数据库
Class.forName("com.microsoft.jdbc.sqlserver.SQLServerDriver").newInstance();
String url="jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=mydb"; //mydb为数据库
String user="sa";
String password="";
Connection conn= DriverManager.getConnection(url,user,password); 
4.Sybase数据库
Class.forName("com.sybase.jdbc.SybDriver").newInstance();
String url =" jdbc:sybase:Tds:localhost:5007/myDB";//myDB为你的数据库名
Properties sysProps = System.getProperties();
SysProps.put("user","userid");
SysProps.put("password","user_password");
Connection conn= DriverManager.getConnection(url, SysProps); 
5.Informix数据库
Class.forName("com.informix.jdbc.IfxDriver").newInstance();
String url = "jdbc:informix-sqli://123.45.67.89:1533/myDB:INFORMIXSERVER=myserver;
user=testuser;password=testpassword"; //myDB为数据库名
Connection conn= DriverManager.getConnection(url); 
6.MySQL数据库
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
String url ="jdbc:mysql://localhost/myDB?user=soft&password=soft1234&useUnicode=true&characterEncoding=8859_1" //myDB为数据库名
Connection conn= DriverManager.getConnection(url); 
7.PostgreSQL数据库
Class.forName("org.postgresql.Driver").newInstance();
String url ="jdbc:postgresql://localhost/myDB" //myDB为数据库名
String user="myuser";
String password="mypassword";
Connection conn= DriverManager.getConnection(url,user,password); 
8.access数据库直连用ODBC的
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver") ;
String url="jdbc:odbc:Driver={MicroSoft Access Driver (*.mdb)};DBQ="+application.getRealPath("/Data/ReportDemo.mdb");
Connection conn = DriverManager.getConnection(url,"","");
Statement stmtNew=conn.createStatement() ;

J2EE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层应用提供了功能支持。在本文中将解释支撑J2EE的13种核心技术：

JDBC,JNDI,EJBs,RMI,JSP,Javaservlets,XML,JMS,JavaIDL,JTS, JTA,JavaMail和JAF，同时还将描述在何时、何处需要使用这些技术。当然，我还要介绍这些不同的技术之间是如何交互的。此外，为了让您更好地 感受J2EE的真实应用，将在WebLogic应用服务器,来自BEA Systems公司的一种广为应用的产品环境下来介绍这些技术。不论对于Web Logic应用服务器和J2EE的新手，还是那些想了解J2EE能带来什么好处的项目管理者和系统分析员，相信本文一定很有参考价值。

一、宏观印象:分布式结构和J2EE

过去，二层化应用--通常被称为client/server应用--是大家谈论的最多的。在很多情况下，服务器提供的惟一服务就是数据库服务。在这 种解决方案中，客户端程序负责数据访问、实现业务逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。client/server结构通常 在第一次部署的时候比较容易，但难于升级或改进，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。更重要的 是，在Web时代，二层化应用通常不能体现出很好的伸缩性，因而很难适应Internet的要求。

Sun设计J2EE的部分起因就是想解决二层化结构的缺陷。于是，J2EE定义了一套标准来简化N层企业级应用的开发。它定义了一套标准化的组件，并为这些组件提供了完整的服务。J2EE还自动为应用程序处理了很多实现细节，如安全、多线程等。

用J2EE开发N层应用包括将二层化结构中的不同层面切分成许多层。一个N层化应用A能够为以下的每种服务提供一个分开的层：

显示：在一个典型的Web应用中，客户端机器上运行的浏览器负责实现用户界面。 字串1

动态生成显示:尽管浏览器可以完成某些动态内容显示，但为了兼容不同的浏览器，这些动态生成工作应该放在Web服务器端进行，使用JSP、Servlets，或者XML（可扩展标记语言）和（可扩展样式表语言）。 字串6

业务逻辑：业务逻辑适合用SessionEJBs（后面将介绍）来实现。

数据访问：数据访问适合用EntityEJBs（后面将介绍）和JDBC来实现。

后台系统集成:同后台系统的集成可能需要用到许多不同的技术，至于何种最佳需要根据后台系统的特征而定。

您可能开始诧异：为什么有这么多的层？事实上，多层方式可以使企业级应用具有很强的伸缩性，它允许每层专注于特定的角色。例如，让Web服务器负责提供页面，应用服务器处理应用逻辑，而数据库服务器提供数据库服务。

由于J2EE建立在Java2平台标准版（J2SE）的基础上，所以具备了J2SE的所有优点和功能。包括“编写一次，到处可用”的可移植性、通过 JDBC访问数据库、同原有企业资源进行交互的CORBA技术，以及一个经过验证的安全模型。在这些基础上，J2EE又增加了对EJB（企业级Java组 件）、Javaservlets、Java服务器页面（JSPs）和XML技术的支持。

二、分布式结构与WebLogic应用服务器

J2EE提供了一个框架--一套标准API--用于开发分布式结构的应用，这个框架的实际实现留给了第三方厂商。部分厂商只是专注于整个J2EE架 构中的的特定组件，例如Apache的Tomcat提供了对JSP和servlets的支持，BEA系统公司则通过其WebLogic应用服务器产品为整 个J2EE规范提供了一个较为完整的实现。

WebLogic服务器已使建立和部署伸缩性较好的分布式应用的过程大为简化。WebLogic和J2EE代你处理了大量常规的编程任务，包括提供事务服务、安全领域、可靠的消息、名字和目录服务、数据库访问和连接池、线程池、负载平衡和容错处理等。

通过以一种标准、易用的方式提供这些公共服务，象WebLogic服务器这样的产品造就了具有更好伸缩性和可维护性的应用系统，使其为大量的用户提供了增长的可用性。

J2EE技术

在接下来的部分里，我们将描述构成J2EE的各种技术，并且了解WebLogic服务器是如何在一个分布式应用中对它们进行支持的。最常用的J2EE技术应该是JDBC、JNDI、EJB、JSP和servlets，对这些我们将作更仔细的考察。

三、Java Database Connectivity(JDBC)

JDBCAPI以一种统一的方式来对各种各样的数据库进行存取。和ODBC一样，JDBC为开发人员隐藏了不同数据库的不同特性。另外，由于JDBC建立在Java的基础上,因此还提供了数据库存取的平台独立性。 字串5

JDBC定义了4种不同的驱动程序，现分述如下：

类型1:JDBC-ODBCBridge

在JDBC出现的初期，JDBC-ODBC桥显然是非常有实用意义的，通过JDBC-ODBC桥，开发人员可以使用JDBC来存取ODBC数据源。 不足的是，他需要在客户端安装ODBC驱动程序，换句话说，必须安装MicrosoftWindows的某个版本。使用这一类型你需要牺牲JDBC的平台 独立性。另外，ODBC驱动程序还需要具有客户端的控制权限。

类型2:JDBC-nativedriverbridge

JDBC本地驱动程序桥提供了一种JDBC接口，它建立在本地数据库驱动程序的顶层，而不需要使用ODBC。JDBC驱动程序将对数据库的API从标准的JDBC调用转换为本地调用。使用此类型需要牺牲JDBC的平台独立性，还要求在客户端安装一些本地代码。 字串3

类型3:JDBC-networkbridge

JDBC网络桥驱动程序不再需要客户端数据库驱动程序。它使用网络上的中间服务器来存取数据库。这种应用使得以下技术的实现有了可能，这些技术包括 负载均衡、连接缓冲池和数据缓存等。由于第3种类型往往只需要相对更少的下载时间，具有平台独立性，而且不需要在客户端安装并取得控制权，所以很适合于 Internet上的应用。

类型4:PureJavadriver

第4种类型通过使用一个纯Java数据库驱动程序来执行数据库的直接访问。此类型实际上在客户端实现了2层结构。要在N-层结构中应用，一个更好的做法是编写一个EJB，让它包含存取代码并提供一个对客户端具有数据库独立性的服务。

WebLogic服务器为一些通常的数据库提供了JDBC驱动程序，包括Oracle,Sybase,MicrosoftSQLServer以及 Informix。它也带有一种JDBC驱动程序用于Cloudscape，这是一种纯Java的DBMS，WebLogic服务器中带有该数据库的评估 版本。

以下让我们看一个JDBC实例：在这个例子中我们假定你已经在Cloudscape中建立了一个PhoneBook数据库，并且包含一个表，名为 CONTACT_TABLE，它带有2个字段：NAME和PHONE。开始的时候先装载CloudscapeJDBCdriver，并请求 drivermanager得到一个对PhoneBookCloudscape数据库的连接。通过这一连接，我们可以构造一个Statement对象并用 它来执行一个简单的SQL查询。最后，用循环来遍历结果集的所有数据，并用标准输出将NAME和PHONE字段的内容进行输出。

import java.sql.*; 字串5 public class JDBCExample{public static void main( String args[] ){try{Class.forName("COM.cloudscape.core.JDBCDriver");Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");Statement stmt = conn.createStatement();String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BYname";ResultSet resultSet = stmt.executeQuery( sql ); 字串8 String name;String phone;while ( resultSet.next() ){name = resultSet.getString(1).trim();phone = resultSet.getString(2).trim();System.out.println( name + ", " + phone ); }catch ( Exception e ){// Handle exception heree.printStackTrace();}}}

OK。接着来看一看JDBC是如何在企业应用中的进行使用。

JDBC在企业级应用中的应用。以上实例其实是很基本的，可能有些微不足道。它假定了一个2层结构。在一个多层的企业级应用中，更大的可能是在客户 端和一个EJB进行通信，该EJB将建立数据库连接。为了实现和改进可伸缩性和系统性能， WebLogic服务器提供了对连接缓冲池connection pool的支持。

Connection pool减少了建立和释放数据库连接的消耗。在系统启动以后即可建立这样的缓冲池，此后如故再有对数据库的请求，WebLogic服务器可以很简单地从缓 冲池中取出数据。数据缓冲池可以在WebLogic服务器的 weblogic.properties 文件中进行定义。

在企业级应用的另一个常见的数据库特性是事务处理。事务是一组申明statement，它们必须做为同一个statement来处理以保证数据完整 性。缺省情况下JDBC使用 auto-commit 事务模式。这可以通过使用Connection类的setAutoCommit() 方法来实现。现在已经对JDBC有了一些认识，下面该转向JNDI了。

四、Java Naming and Directory Interface (JNDI) 字串3

JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统，后者在应用服务器中的对象。在JNDI 中，在目录结构中的每一个结点称为context。每一个JNDI名字都是相对于context的。这里没有绝对名字的概念存在。对一个应用来说，它可以 通过使用 InitialContext 类来得到其第一个context: 字串6

Context ctx = new InitialContext();

应用可以通过这个初始化的context经有这个目录树 来定位它所需要的资源或对象。例如，假设你在Weblogic服务器中展开了一个EJB并将home接口绑定到名字 myApp.myEJB ，那么该EJB的某个客户在取得一个初始化context以后，可以通过以下语句定位home接口：

MyEJBHome home = ctx.lookup( "myApp.myEJB" );

在这个例子中，一旦你有了对被请求对象的参考，EJB的home接口就可以在它上面调用方法。我们将在下面的"Enterprise Java Beans"章节中做更多的介绍。

以上关于JNDI的讨论只是冰山之一角而已。如果要更进一步地在context中查找对象，JNDI也提供了一些方法来进行以下操作：将一个对象插 入或绑定到context。这在你展开一个EJB的时候是很有效的。从context中移去对象。列出context中的所有对象。创建或删除子一级的 context。接下来，要开始关注EJB了。
五、Enterprise Java Beans (EJB)

J2EE技术之所以赢得某体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度 复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全性、资 源缓冲池以及容错性。 字串8

EJB规范定义了三种基本的bean类型:

Stateless session beans: 提供某种单一的服务，不维持任何状态，在服务器故障发生时无法继续存在，生命期相对较短。例如，一个stateless sessionbean可能被用于执行温度转换计算。

Stateful session bean: T提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。Stateful session bean在服务器故障时无法继续生存，生命气相对较短。每一个实例只用于一个单个的线程。

Entity beans: 提供了一致性数据的表示-- 通常存放在数据库中 -- 在服务器故障发生后能继续存在。多用户情况下可以使用EJB来表示相同的数据。entity EJB的一个典型例子是客户的帐号信息。 字串2

尽管有以上的区别，所有的EJB还是有许多的共同之处。它们都处理homeinterface。它定义了一个客户端是如何创建与消亡EJB的。可以 在bean中对定义了客户端方法的远程接口进行调用；bean类则执行了主要的商务逻辑。描述EJB的开发已经超出了本文的范围。但是，如果一个EJB已 经被开发了或者从第三方进行了购买，它就必须在应用服务器中进行发布。WebLogic Server 5.1带有一个EJB Deployer Tool来协助处理EJB的发布。当你使用EJB Deployer Tool的时候，你要定义客户端所用的JNDI名字来定位EJB。Deployer Tool将生成wrapper类来处理和容器的通信以及在一个jar文件中把被请求的Java类绑定在一起。

一旦EJB被发布，客户端就可以使用它的JNDI名字来定位EJB。首先，它必须得到一个到home接口的reference。然后，客户端可以使 用该接口，调用一个create() 方法来得到服务器上运行的某个bean实例的句柄；最后，客户端可以使用该句柄在bean中调用方法。了解 EJB后，让我们再来看JSP。 字串4

六、JavaServer Pages (JSPs) 字串4

可能已经有许多人已经熟悉Microsoft的Active Server Pages(ASP)技术了。JSP和ASP相对应的，但更具有平台对立性。他们被设计用以帮助Web内容开发人员创建动态网页，并且只需要相对较少的代 码。 即使Web设计师不懂得如何编程也可以使用JSP，因为JSP应用是很方便的。 JSP页面由HTML代码和嵌入其中的Java代码所组成。服务器在页面被客户端所请求以后对这些Java代码进行处理，然后将生成的HTML页面返回给 客户端的浏览器。 字串5

下面来看一个JSP的简单实例。它只显示了服务器的当前日期和时间。虽然，对语法的具体解释已经超出了本文的范围，但我们还是可以很直观地看到，Java代码被放在 符号的中间，而Java的表达式则放在符号之间。

＜H1＞Date JSP sample＜/H1＞＜H2＞＜% response.setHeader("Refresh", 5); %＞The current date is ＜%= new Date() %＞.＜/H2＞ 字串1

下面是: Java servlets

七、Java Servlets

Servlet 提供的功能大多与JSP类似，不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的Java代码，而servlets全部由Java写成并且 生成HTML。Servlet是一种小型的Java程序，它扩展了Web服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI Perl脚本很相似。Servlets和CGI脚本的一个很大的区别是：每一个CGI在开始的时候都要求开始一个新的进程 -- 而servlets是在servlet引擎中以分离的线程来运行的。因此servlets在可伸缩性上提供了很好的改进。

在开发servlets的时候，您常常需要扩展javax.servlet.http.HttpServlet类，并且override一些它的方法，其中包括：

service(): 作为dispatcher来实现命令-定义方法

doGet(): 处理客户端的HTTP GET请求。

doPost(): 进行HTTP POST操作 字串7

其它的方法还包括处理不同类型的HTTP请求 -- 可以参考HttpServlet API文档。以上描述的是标准J2EE Servlet API的各种方法。WebLogic服务器提供了一个该API完整的实现途径。一旦你开发了一个servlet，你就可以在 weblogic.properties 中加以注册并由此可以在WebLogic服务器中对它进行配置。 字串8

通过Java servlets,我们已经到达了J2EE主要技术的末尾了。但J2EE所提供的并不止于这些。下面的段落中我们将简要地看一下现存的一些技术，包括RMI,Java IDL和CORBA, JTA, 以及XML，等等。 字串1

八、Remote Method Invocation (RMI)

正如其名字所表示的那样，RMI协议是在远程对象上调用一些方法。它使用了连续序列方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更下层的协议。 字串5

九、Java IDL/CORBA 字串5

在Java IDL的支持下，开发人员可以将Java和CORBA集成在一起。 他们可以创建Java对象并使之可在CORBA ORB中展开, 或者他们还可以创建Java类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径，通过它Java可以被用于将你的新的应 用和legacy系统相集成。 字串4

十、Java Transaction Architecture (JTA)/Java Transaction Service (JTS)

JTA定义了一种标准的API，应用系统由此可以存取各种事务监控。JTS是CORBA OTS事务监控的基本的实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持Java Transaction API (JTA)规范，并且在较底层实现OMG OTS specification的Java映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

十一、JavaMail and JavaBeans Activation Framework

JavaMail是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。仅支持SMTP服务器，也支持IMAP服务器。JavaMail 利用JavaBeans Activation Framework (JAF)来处理MIME-编码的邮件附件。MIME的字节流可以被转换成Java对象，或者转换自Java对象。由此大多数应用都可以不需要直接使用 JAF。

十二、Java Messaging Service (JMS)

JMS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域，有支持发布/订阅(publish/subscribe) 类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用 与legacy backend系统相集成。

十三、Extensible Markup Language (XML) 字串7

XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。XML的发展和Java是相互独立的，但是，它和Java具有 的相同目标正是平台独立性。通过将Java和XML的组合，您可以得到一个完美的具有平台独立性的解决方案。目前正有许多不同的公司在为Java和XML 的组合而努力。如果要了解更多的这方面的信息，可以访问Sun的Java-XML页面，或者IBM developerWorks的XML Zone。