现在几乎所有的应用系统都无法避免使用数据库系统。在JAVA世界里访问数据库是一件非常轻松的事情，JDBC为JAVA应用程序访问数据库提供了一个统一的接口，通过使用JDBC接口开发者无需关心系统最终采用哪种数据库，因为JDBC仅仅是定义了访问几个JAVA的接口类，具体的实现是由数据库厂商提供的，这种做法其实与其他数据库连接方式例如ODBC是类似的。但是在实际的应用过程中，开发者发现离JDBC设计的初衷还是有一定距离，就比如说在存储字符串时的编码问题，我想很多开发者都会遇见这个问题，倒不是因为说解决它有什么技术方面的难度，而是它的的确确非常繁琐。我们必须在每次写入或者读出字符串的时候进行编码和反编码处理；或者说我们可以写一个方法可以进行编码处理的，但又必须在每次数据库操作的时候调用，虽然调用很简单，可是我非得这样吗？要是忘了编码那又要DEBUG了。当然你可能觉得这并没有什么，或者你可能很勤快，喜欢写大量重复的代码，可是你难道没有觉得这种繁琐的工作正在浪费你过于宝贵的青春吗？停止你的键盘输入，让我们来解决这个问题吧！

　　解决思路

　　在传统的应用程序中数据库操作部分我们可以想象成两层，如图所示：一个是数据库的"连接池"，另外一个业务数据操作层。在这里数据库的连接池是广义的，你可以把JDBC中的DriverManager也当成是连接池，具体的意思就是我们可以通过这层来获取到指定数据库的连接而不去关心它是怎么获取的。如果这个时候数据库系统（有如Informix，SQL Server）要求对字符串进行转码才能存储（例如最常见的GBK->ISO8859_1转码），那我们就必须在业务数据操作层来进行，这样有多少业务数据操作我们就要做多少编码转码的工作，太麻烦了，代码中充斥中大量重复的内容。本文提出的解决方案就是利用对获取到的数据库连接实例进行二次封装，也就是在数据库连接池与业务数据操作层之间加入了连接封装层，当然了，我们也完全可以直接将连接封装集成到数据库连接池内部。关于连接池的实现请参照我的另外一篇文章《使用JAVA动态代理实现数据库连接池》

图一

　　我们知道进行编码和转码工作都是集中在JDBC的两个接口PreparedStatement和ResultSet上进行的，主要涉及PreparedStatement的setString方法以及ResultSet的getString方法。前面我们讲过需要加入一个连接封装层来对数据库连接实例进行二次封装，但是怎么通过这个封装来改变PreparedStatement和ResultSet这两个接口的行为呢？这个问题其实也很简单，因为PreparedStatement接口必须通过Connection接口来获取实例，而ResultSet接口又必须从Statement或者PreparedStatement接口来获取实例，有了这样的级联关系，问题也就迎刃而解了。还是利用我在文章《使用JAVA动态代理实现数据库连接池》中使用的动态接口代理技术。首先我们设计Connection接口的代理类_Connection，这个代理类接管了Connection接口中所有可能获取到Statement或者PreparedStatement接口实例的方法，例如：prepareStatement和createStatement。改变这两个方法使之返回的是经过接管后的Statement或者PreparedStatement实例。通过对于Statement接口也有相应的代理类_Statement，这个代理类接管用于获取ResultSet接口实例的所有方法，包括对setString方法的接管以决定是否对字符串进行编码处理。对于接口ResultSet的接管类_ResultSet就相应的比较简单，它只需要处理getString方法即可。

　　关键代码

　　前面我们大概介绍了这个解决方案的思路，下面我们给出关键的实现代码包括Connection的代理类，Statement的代理类，ResultSet的代理类。这些代码是在原来关于数据库连接池实现的基础上进行扩充使之增加对自动编码处理的功能。有需要源码打包的可以通过电子邮件跟我联系。

_Connection.java

/*
 * Created on 2003-10-23 by Liudong
 */
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/*
 *
 * 数据库连接的代理类
 * @author Liudong
 */
 class _Connection implements InvocationHandler{
 private Connection conn = null;
 private boolean coding = false;
 //指定是否进行字符串转码操作
 _Connection(Connection conn, boolean coding){
  this.conn = conn;
  this.coding = coding;
  initConnectionParam(this.conn);
 
 }
 
 /** 
  * Returns the conn. 
  * @return Connection 
  */
 
 public Connection getConnection() {
  Class[] interfaces = conn.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = Connection.class;
  
  }
 
  Connection conn2 = (Connection)Proxy.newProxyInstance( conn.getClass().getClassLoader(), interfaces,this);
  return conn2;
 
 }
 
 /** 
  * @see java.lang.reflect.InvocationHandler#invoke 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  //调用相应的操作
  Object obj = null;
  try{
   obj = m.invoke(conn, args);
   //接管用于获取语句句柄实例的方法
   if((CS.equals(method)||PS.equals(method))&&coding)
    return new _Statement((Statement)obj,true).getStatement();
  
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
  }
  return obj;
 }
 
 private final static String PS = "prepareStatement";
 private final static String CS = "createStatement";
}

_Statement.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.*;
import java.lang.reflect.*;

/**
 * 数据库语句对象实例的代理类
 * @author Liudong
 */
class _Statement implements InvocationHandler{ 
 private Statement statement ; //保存所接管对象的实例 
 private boolean decode = false; //指定是否进行字符串转码 

 public _Statement(Statement stmt,boolean decode) { 
  this.statement = stmt;
  this.decode = decode;
 }
 
 /** 
  * 获取一个接管后的对象实例 
  * @return 
  */
 public Statement getStatement() {
  Class[] interfaces = statement.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){ 
   interfaces = new Class[1];
   interfaces[0] = Statement.class;
  } 
  Statement stmt = (Statement)Proxy.newProxyInstance(   
   statement.getClass().getClassLoader(), 
   interfaces,this);
  return stmt;
 
 }
 
 /** 
  * 方法接管 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
  String method = m.getName(); //接管setString方法 
  if(decode && SETSTRING.equals(method)) {
   try{
    String param = (String)args[1];
    if(param!=null)
     param = new String(param.getBytes(),"8859_1");
    return m.invoke(statement,new Object[]{args[0],param});
   } catch(InvocationTargetException e){
    throw e.getTargetException();
        
   }  
  }
  
  //接管executeQuery方法
  
  if(decode && EXECUTEQUERY.equals(method)){
   try{
    ResultSet rs = (ResultSet)m.invoke(statement,args);
    return new _ResultSet(rs,decode).getResultSet();
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }  
  }
  
  try{
   return m.invoke(statement, args);
  } catch(InvocationTargetException e) {
   throw e.getTargetException();
   } 
 }
 //两个要接管的方法名
 
 private final static String SETSTRING = "setString";
 private final static String EXECUTEQUERY = "executeQuery";
}

_ResultSet.java

/*
 * Created on 2003-10-23 by Liudong
 */
 
package lius.pool;
import java.sql.ResultSet;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * 数据库结果集的代理类
 * @author Liudong
 */
 class _ResultSet implements InvocationHandler{ 
 private ResultSet rs = null;
 private boolean decode = false;
 
 public _ResultSet(ResultSet rs,boolean decode) {
  this.rs = rs;
  this.decode = decode;
 }
 
 public ResultSet getResultSet(){ 
  Class[] interfaces = rs.getClass().getInterfaces();
  if(interfaces==null||interfaces.length==0){
   interfaces = new Class[1];
   interfaces[0] = ResultSet.class;  
  }
 
  ResultSet rs2 = (ResultSet)Proxy.newProxyInstance(rs.getClass().getClassLoader(),interfaces,this);
  return rs2;
 
 }

 /** 
  * 结果getString方法 
  */
 public Object invoke(Object proxy, Method m, Object[] args) throws Throwable { 
  String method = m.getName();
  if(decode && GETSTRING.equals(method)){
   try{
    String result = (String)m.invoke(rs,args);
    if(result!=null)     
     return new String(result.getBytes("8859_1"));
    return null;
   
   }catch(InvocationTargetException e){
    throw e.getTargetException();
    }
   
  } 
  
  try{
   return m.invoke(rs, args);
  }catch(InvocationTargetException e){
   throw e.getTargetException();
  }
 }
 
 private final static String GETSTRING = "getString";

}

　　现在我们已经把三个接口的代理类做好了，下一步就是怎么来使用这三个类。其实对于使用者来讲并不需要关心三个类，只需要了解_Connection就可以了，因为另外两个是_Connection直接调用的。为了使用_Connection我们必须传入两个参数，第一个是数据库实际的数据库连接实例，另外一个是布尔值代表是否进行转码处理。我们必须先通过实际的情况获取到数据库连接后再传入_Connection的构造函数作为参数，下面例子告诉你如何来使用_Connection这个类：

　　Connection conn = getConnection(); //获取数据库连接
　　boolean coding = false; //从配置或者其他地方读取是否进行转码的配置 
　　//接管数据库连接实例 
　　_Connection _conn = new _Connection(conn,coding);
　　//获得接管后的数据库连接实例，以后直接使用conn2而不是conn 
　　Connection conn2 = _conn.getConnection();

　　因为对一个应用系统来讲，数据库连接的获取必然有统一的方法，在这个方法中加入对连接的接管就可以一劳永逸的解决数据库的编码问题。

　　性能比较

　　功能没有问题了，开发者接下来就会关心性能的问题，因为在进行一些对响应速度要求很高或者大数据量的处理情况下性能就成为一个非常突出的问题。由于JAVA中的动态接口代理采用的是反射（Reflection）机制，同时又加入我们自己的一些代码例如方法名判断，字符串转码等操作因此在性能上肯定比不上直接使用没有经过接管的数据库连接。但是这点性能上的差别是不是我们可以忍受的呢，为此我做了一个试验对二者进行了比较：

　　测试环境简单描述：

　　使用ACCESS数据库，建两张结构一样的表，计算从获取连接后到插入数据完毕后的时间差，两个程序（直连数据库和使用连接接管）都进行的字符串的转码操作。

　　测试结果：

　　从上面这张测试结果表中来看，二者的性能的差别非常小，尽管在两万条数据的批量插入的时候时间差别也不会多于一秒钟，这样的结果应该说还是令人满意的，毕竟为了程序良好的结构有时候牺牲一点点性能还是值得的。

　　本文算是我之前文章《使用JAVA动态代理实现数据库连接池》中提出的数据库连接池实现的进一步完善，同样使用动态接口代理的技术来解决数据库编码的问题。JAVA的这个高级技术可以用来解决许多实际中非常棘手的问题，就像本文提到的编码问题的处理以及数据库连接池的实现，同时在WEB开发框架的实现上也有非常大的作为。欢迎对这方面感兴趣的朋友来信共同来研究。

from: http://www.javafan.net/article/20041212111952983.html

JAVA的中文问题比较突出，主要表现在控制面板输出，JSP页面输出和数据库访问上。本文尽量避开字体问题，而只谈编码。通过本文，你可以了解JAVA中文问题的由来，问题的解决方法，其中提了一下用JDBC访问数据库的方法。

二、问题描述：

1）在中文W2000中文窗口编译和运行，用的是国际版的JDK，连接的是中文W2000下的Cp936编码的SQL SERVER数据库：

J:\exercise\demo\encode\HelloWorld>make

Created by XCompiler. PhiloSoft All Rights Reserved.

Wed May 30 02:54:45 CST 2001

J:\exercise\demo\encode\HelloWorld>run

Created by XRunner. PhiloSoft All Rights Reserved.

Wed May 30 02:51:33 CST 2001

中文

[B@7bc8b569

[B@7b08b569

[B@7860b569

中文

中文

????

中文

中文

????

??

??

??

2）如果在中文W2000的西文窗口（编码为437）下编译，用JAVA运行则由于无字体而无法正常显示，如果象上面一样在中文W2000的中文窗口运行，输出为：

J:\exercise\demo\encode\HelloWorld>run

Created by XRunner. PhiloSoft All Rights Reserved.

Wed May 30 02:51:33 CST 2001

????

[B@7bc0b66a

[B@7b04b66a

[B@7818b66a

????

????

????

????

????

????

中文

中文

????

三）分析

1）出现有乱码（也就是？）。由于只出现？而没出现小方框，说明只是编码有问题，而不是字体问题。 在编码中，如果从一种字符集转换到别一种字符集，比较典型的是从GB2312转换到ISO8859_1（即ASCII），那么很多汉字（半个汉字）是无法映射到西文字符中去的，在这种情形下，系统就把这些字符用？代替。同样，也存在小字符集无法到大字符集的情况，具体原因这里就不详谈了。

2）出现了中文环境编译，中文环境运行时汉字显示有正确也有不正确的地方，同样，在西文环境下编译，在中文环境下运行时也出现类似情况。这是由于自动（默认）或手工（也就new String(bytes[,encode])和bytes getBytes([encode])）转码的结果。

2.1）在JAVA源文件-->JAVAC-->Class-->Java-->getBytes()-->new String()-->显示的过程中，每一步都有编码的转换过程，这个过程总是存在的，只是有的时候用默认的参数进行。下面我们一步一步分析为什么出现上面的情形。

2.2）这里是源代码：

HelloWorld.java:

------------------------

public class HelloWorld

{

public static void main(String[] argv){

try{

System.out.println("中文");//1

System.out.println("中文".getBytes());//2

System.out.println("中文".getBytes("GB2312"));//3

System.out.println("中文".getBytes("ISO8859_1"));//4

System.out.println(new String("中文".getBytes()));//5

System.out.println(new String("中文".getBytes(),"GB2312"));//6

System.out.println(new String("中文".getBytes(),"ISO8859_1"));//7

System.out.println(new String("中文".getBytes("GB2312")));//8

System.out.println(new String("中文".getBytes("GB2312"),"GB2312"));//9

System.out.println(new

String("中文".getBytes("GB2312"),"ISO8859_1"));//10

System.out.println(new String("中文".getBytes("ISO8859_1")));//11

System.out.println(new

String("中文".getBytes("ISO8859_1"),"GB2312"));//12

System.out.println(new

String("中文".getBytes("ISO8859_1"),"ISO8859_1"));//13

}

catch(Exception e){

e.printStackTrace();

}

}

}

为了方便起见，在每个转换的后面加了操作序号，分别为1,2,...,13。

2.3）需要说明的是，JAVAC是以系统默认编码读入源文件，然后按UNICODE进行编码的。在JAVA运行的时候，JAVA也是采用UNICODE编码的，并且默认输入和输出的都是操作系统的默认编码，也就是说在new String(bytes[,encode])中，系统认为输入的是编码为encode的字节流，换句话说，如果按encode来翻译bytes才能得到正确的结果，这个结果最后要在JAVA中保存，它还是要从这个encode转换成Unicode，也就是说有bytes-->encode字符-->Unicode字符的转换；而在String.getBytes([encode])中，系统要做一个Unicode字符-->encode字符-->bytes的转换。

在这个例子中，除那个英文窗口编码的时候除外，其实情形下默认编码都是GBK（在本例中，我们暂且把GBK和GB2312等同看待）。

2.4）由于在未指明在上面的两个用代码实现的转换中，如果未指定encode，系统将采用默认的编码（这里为GBK），我们认为上面的5,6,7和8,9,10是一样的，8和9、11和12也是一样的，所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试，不在我们的讨论范围之内。

2.5）下面我们来跟踪程序中的“中”字的转换历程，我们先说在中文窗口下作的编译和运行过程，注意在下面的字母下标中，我有意识地使用了一些数字，以表示相同，相异还是相关2.5.1)我们先以上面的13个代码段中的的代码9为例：

步骤 内容 地点 说明

01： C1 HelloWorld.java C1泛指一个GBK字符

02： U1 JAVAC读取 U1泛指一个Unicode字符

03： C1 getBytes()第一步 JAVA先和操作系统交流

04： B1,B2 getBytes()第二步 然后返回字节数组

05： C1 new String()第一步 JAVA先和操作系统交流

06： U1 new String()第二步 然后返回字符

07： C1 println(String) 能显示“中”字，内容和原来的相同

2.5.2）然后再以代码段10为例，我们注意到只是：

步骤 内容 地点 说明

01： C1 HelloWorld.java C1泛指一个GBK字符

02： U1 JAVAC读取 U1泛指一个Unicode字符

03： C1 getBytes()第一步 JAVA先和操作系统交流

04： B1,B2 getBytes()第二步 然后返回字节数组

05： C3,C4 new String()第一步 JAVA先和操作系统交流，这时解析错误

06： U5,U6 new String()第二步 然后返回字符

07： C3,C4 println(String) 由于中字给分成了两半，在ISO8859_1中刚好也没有字符

能映射上，所以显示为“??”。在上面的示例中，

“中文”两个字就显示为“？？？？”

2.5.3）在完全中文模式下的其它情形类似，我就不多说了

2.6）我们接着看为什么在西文DOS窗口下编译出来的类在中文窗口下也出现类似情形，特别是为什么居然有的情形下还能正确显示汉字。

2.6.1）我们还是先以代码段9为例：

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开

02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符

03： C5C6 getBytes()第一步 JAVA先和操作系统交流，这时解析错误

04： B5B6B7B8 getBytes()第二步 然后返回字节数组

05： C5C6 new String()第一步 JAVA先和操作系统交流

06： U3U4 new String()第二步 然后返回字符

07： C5C6 println(String) 虽然同是两个字符，但已不是最初的“两个ISO8859_1字

符”，而是“两个BGK字符”，“中”显示成了“？？”

而“中文”就显示成了“？？？？”

2.6.2）下面我们以代码段12为例，因为它能正确显示汉字

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开

02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符

03： C1C2 getBytes()第一步 JAVA先和操作系统交流（注意还是正确的哦！）

04： B5B6 getBytes()第二步 然后返回字节数组（这是很关键的一步！）

05： C12 new String()第一步 JAVA先和操作系统交流（这是更关键的一步，JAVA已经知道B5B6要解析成一个汉字！）

06： U7 new String()第二步 然后返回字符（真是一个项两！U7包含了U3U4的信息）

07： C12 println(String) 这就原来的“中”字，很委屈被JAVAC冤枉了一回，不过被程序员拨乱反正了一下！当然，“中文”两个字都能正确显示了！

3）那为什么有的时候用JDBC的

new String(Recordset.getBytes(int)[,encode])

Recordset.getSting(int)

Recordset.setBytes(String.getBytes([encode]))

和

Recordset.setString(String)

的时候会出现乱码了呢？

其实问题就出现在编写JDBC的的也考虑了编码问题，它从数据库读取数据后，可能自作主张做了一个从GB2312（默认编码）到Unicode的转换，我的这个WebLogic For SQL Server的JDBC Driver就是这样的，当我读字串的时候，发出读到的不是正确的汉字，可恨的是我却可以直接写汉字字串，这让人多少有点难以接受！

也就是说，我们不得不在读或写的时候进行转码，尽管这个转码有的时候不是那么明显，这是因为我们使用了默认的编码进行转码。JDBC Driver所做的操作，我们只有进入到源代码内部才能清楚，不是吗？

from: http://java.ccidnet.com/art/3737/20060605/571079_1.html

(4)如果是通过"a.jsp?param=中文"传递参数,则需要:
     a.在传参数之前先把参数进行转码:java.net.URLEncoder.encode(param);
       取值用java.net.URLDncoder.decode(param);再转回中文
     b.在你的Tomcat目录-->conf目录-->server.xml里找出这段:
       <Connector
         port="8080"               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true" <!--在里边加上这个参数-->URIEncoding="gb2312"/>

from: http://www.yuanma.org/data/2006/0911/article_1503.htm

l         为应用选择最好最快的 JDBC 驱动 ,参考本站文章 。 JDBC3.0提供了新的特性来提高性能，诸如连接池， statemente池的改进  

l        对数据库使用连接池并且重用连接，而不要重复打开和关闭连接。最佳的连接池大小是当连接池大到足够使服务请求不等待

l         尽量使用支持 JDBC3.0 的驱动，因为 JDBC3.0 支持包括 DataSource 对象，连接池，分布式事务支持， RowSets 和 prepared statement 池等性能增强特性

l         Prepared statement 池（自从 JDBC3.0 开始有）高速缓存已经预先优化并运行了的 SQL 查询，这样，他们被再次请求的时候，不必经历再次的优化预处理（避免最优化步骤，诸如检查语法，验证地址，优化访问路径和执行计划）。 Statement 池是一个很好的，重要的性能优化方法

l         JDBC3.0 中的 Statement 池和连接池能合作共享 statement 池，这样，能使用一个已高速缓存的 statement （该 statement 来自另外一个连接）的连接，在由任一连接执行的 一些SQL 首次被执行时，产生的 statement 准备开销仅一次

l         RowSet对象与 ResultSet 对象相似，但是能提供当断开连接的时候对数据库数据的访问。这允许数据以它最简单的形式被高效的高速缓存

l         用同一个连接执行多个 statements

l         关闭 autocommit ，但不要让事务打开太久

l         避免将事务分布开（事务跨越多个连接）

l         最小化数据库的行和列数据获取。使用 setMaxRows, setMaxFieldSize,和 SetFetchSize

l         使用最高效的数据类型：字符串比整数型快，整数型比浮点类型和时间戳类型都要高效（是否不太理解^&^，这是针对DB2数据库处理来说的，处理character类型最快，而处理integer类型通常需要一些转换或者字节排序）

l         使用 updateXXX()方法更新： updateXXX() 在可更新的结果集上调用。结果集已经定位到了一行 , 因此当使用一个 UPDATE statement 时，可以消除通常的查找要更新的数据行的开销

l         Cache任何请求的元数据（ metadata ）并尽可能少的使用元数据 方法，其慢的程度一用便知

l         避免在元数据 查询中使用 null 参数

l         使用虚拟查询获得一行的元数据，不要使用getcolumns()（假如应用允许用户使用列数据，应用是使用getColumns来返回列的信息给用户还是准备一个虚拟查询而后调用getMetadata呢？

l         使用存储过程，避免多余的网络传输

l         在存储过程中使用参量，不要将数据挨个地放在statement中，最小化解析开销。此条针对DB2来说，其它数据库未必适用。SQL总是以字符串形式发送给DB2数据库，例如：
CallableStatement cstmt = conn.prepareCall ("call getCustName (12345)");
ResultSet rs = cstmt.executeQuery ();
DB2服务器必须解析该SQL，验证参量类型，并将参量转化为正确的数据类型。

l         对需要重复执行的statement使用预处理statement（PreparedStatement）

l         选择使用最佳游标：对连续读取使用游标；对双向滚动使用游标。对仅返回一行的查询避免使用游标。

l         在JVM中Cache频繁请求的数据，避免不必要的数据库请求

l         采用预读取机制， 批量取行，而不要一次一行 。调整批大小和预取行的数量。避免使用预取 BLOB 数据。

l         除非绝对需要，否则避免移动数据

l         在数据穿过网络之前要使流化数据（ Streamline data ）

l         避免每次处理一行，尽可能一起处理多行。

l         在表中统计个数（例如：使用 select count(*) from myTable,yourTable where …）属于资源密集型的。试试首先选入临时表，仅返回该计数（count），然后发送精确的二次查询获得临时表中的行的子集。

l         恰当的使用 SQL 能减少资源请求。使用返回所需数据的最小值的查询：避免 select * 查询。一个返回小的数据子集的复杂查询，比一个简单的，返回超过所需的大量数据的简单查询更高效。

l         使你的查询尽可能精巧，例如：尽可能精确地最小化要传输的数据，使其是所需的子集

l         努力批量更新：将 statement 收集到一起，然后在一个事务里面一起执行。如果可能，使用有条件的逻辑和临时变量来达到 statement 批处理

l         永远不要让 DBMS 事务跨越用户输入

l         考虑使用乐观锁。乐观锁使用时间戳验证数据是否还没有被其他用户改变，否则事务失败

l         使用 恰当的更新，例如：更新行/表中已经存在的数据，而不要添加或者删除行/表。在适当的位置更新数据要比移动数据快得多，如果更新需要的空间比表设计能提供的更多，这可能是需要的。如果你设计的行需要空间初始化，更新将会更快。交易是你的表可能需要更多的磁盘空间，但可能速度更快。由于磁盘空间是便宜的，使用一点点能提高性能，这应该说是非常有价值的投资

l         分开存储正在操作的数据和历史数据（更一般的情况是将频繁使用的数据和不常使用的数据分开存储）

l         尽可能小的保留你的操作数据集，避免必须读那些不相关的数据

l         DBMS可以很好的并行运转，尽量将应用设计成当和 DBMS交互时应用能做其他事情。

l         使用流水线操作和并行操作。 将应用设计成支持大量并行进程， 使应用运行更快。如果要处理多步，努力设计好应用，以使后来的步骤能够在任何优先的进程已经完成的数据部分上开始工作，而不是必须等到优先进程完成

l       事物的保护级别越高，性能损失就越大。事物级别按增长的顺序为： TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE。使用Connection.setTransactionIsolation() 设置你想要的事物级别

l      默认的自动提交模式由于使每一个数据库命令都成为一个单独的事务，这会严重影响性能，关闭自动提交（Connection.setAutoCommit(false) ），明确声明事务

l         通过整合多个事务为一个的批量操作，并在一个statement中使用Statement.addBatch() 和Statement.executeBatch()

l       Savepoints (from JDBC3.0)需要昂贵的资源。一旦不再需要，就立刻使用Connection.releaseSavepoint()释放掉Savepoints

l         ConnectionPoolDataSource (from JDBC3.0)和PooledConnection接口为连接池提供了built-in支持

l           使用setLogWriter() (from Driver, DataSource, or ConnectionPooledDataSource; from JDBC3.0) 帮助跟踪JDBC流

l           使用Connection.setReadOnly(true)优化只读数据库（操作）交互

l           使用Connection.nativeSQL()察看SQL查询如何在数据库种执行，帮助确保SQL已被优化

l          切记：一旦可能，立刻关闭Statement和ResultSet

l          使用DatabaseMetaData获得数据库功能性信息

l          一直捕捉和处理数据库警告和异常

l          使用最恰当的数据类型明确数据的类型，例如：以date类型存储日期，儿不要用varchar

l          使用可滚动ResultSet (JDBC 2.0)

from: http://www.ijsp.net/2/2003-9/20/0000431.shtml

2. 对一些稍微复杂些的语句, 例如在对金额等敏感数据操作时, 一个常用的操作序列是:
a. 先取出当前金额
b. 运算后得到更新的金额
c. 执行 Update 语句: Update < tableName > set amount= < New amount > where amount= < Old amount >
这种操作是 ORM 不能支持的, SqlMap 能很好的支持。

3. SqlMap 的 Domain 对象可以直接放在业务层, 一般 ORM 的对数据访问的基类要放在数据访问层(因为带有对数据访问的接口, 放在业务层不合适), 增加了代码的冗余度。

4. 用 ORM 的目的是什么, 最主要的目的是减少重复的底层编程工作量, SqlMap 完全可以做到。

再说说 SqlMap 的不足:

1. 因为不象 ORM 那样生成稳定可靠的对数据访问的基类, 所以要对 Map 操作做好充足的单元测试, 增加了测试的工作量。

2. 每次改动数据库, Map 和 Domain 文件往往要手工修改, 因为 SqlMap 的灵活性, 往往我们会手工调整 Map 而不会直接使用 Generator 生成的代码。

from: http://matrix.foresee.cn/blogs/simon/archives/001638.html

    Servlet API提供了一个Cookie类，封装了对Cookie的基本操作。如下所示。

java.lang.Object
                            |-javax.servlet.http.Cookie
public class Cookie extends Object implements Cloneable
     Cookie类的方法如表14-4所示。

表14-4  Cookie类的方法
方    法                   意    义
Cookie(String, String) 生成一个有名和值的Cookie
clone()                返回当前对象的一个拷贝
getComment()        返回描述该Cookie的注释，没有就为空
getDomain()            返回该Cookie的域名
getMaxAge()            返回该Cookie的最大寿命
getName()            返回该Cookie的名字
getPath()            返回使用该Cookie的所有URL前缀
getSecure()            返回该Cookie的安全标志
getValue()            返回该Cookie的值
getVersion()        返回该Cookie的版本
setComment(String)    设置描述该Cookie的注释
setDomain(String)    设置该Cookie的域名
setMaxAge(int)        设置该Cookie的最大寿命
setPath(String) 设置该Cookie只能被从使用该URL前缀的请求提出
setSecure(boolean)   设置该Cookie的安全标志
setValue(String)   设置该Cookie的值
setVersion(int)       设置该Cookie所使用的协议的版本号
     实例：使用Cookie的Servlet程序

    下面的程序示例14-6就是对Cookie的基本运用。
    【程序源代码】

1 // ==================== Program Description ======================
2 // 程序名称：示例14-6: CookieCounter.java
3 // 程序目的：编写Cookie的Servlet程序
4 // ==========================================================
5 package test.cookie;
6 
7 import java.io.*;
8 import java.util.*;
9 import javax.servlet.*;
10 import javax.servlet.http.*;
11 
12 public class CookieCounter extends HttpServlet {
   public void init(ServletConfig config) throws ServletException {
14       super.init(config);
15    }
16 
   public void service(HttpServletRequest request,
   HttpServletResponse response) throws
18        IOException {
      boolean cookieFound = false;
20       Cookie thisCookie = null;
21       response.setContentType("text/html;charset=gb2312;");
22       PrintWriter out = response.getWriter();
23 
24       Cookie[] cookies = request.getCookies();
25       if (cookies != null){
26          for (int i = 0; i < cookies.length; i++) {
27             thisCookie = cookies[0];
            if (thisCookie.getName().equals("CookieCount")) {
29                cookieFound = true;
30                break;
31             }
32          }
33       }
34 
35       if (cookieFound == false) {
36          thisCookie = new Cookie("CookieCount", "1");
37          thisCookie.setMaxAge(10);
38          response.addCookie(thisCookie);
39       }
40 
41       out.println(" " +
42                   " " +
43                   " " +
44                   "

" +
45                   "

欢迎来到阅微草堂！

这是您在近" + 10 *
(Integer.parseInt((thisCookie.getValue()))-1)
56                    + "秒钟内第 " + thisCookie.getValue() + " 次光临寒舍！

您至少已经10秒钟没有光临寒舍了！

 
    CookieCounter
    test.cookie.CookieCounter
 

 
    CookieCounter
    /CookieCounter
 

    【程序输出结果】如图14-8所示。

（a）

（b）
图14-8 客户端返回有关Cookie的信息

    【程序注解】
    本例是在Resin 2.1.8服务器下调试运行的。首先在webapps目录下建一个名为cookie的Web应用。Servlet编译生成的class文件放在cookie/WEB-INF/classes/test/cookie目录下，web.xml文件直接放在cookie/WEB-INF目录下。由于web.xml中url-pattern的配置为"/CookieCounter"，所以在浏览器中输入"http://localhost:8080/cookie/CookieCounter"即可访问到该Servlet。

    下面对源程序做一简单分析。在service()方法中，用getCookies()函数获得客户端的Cookies，查找是否有名为"CookieCount"的Cookie。如果不存在就生成一个Cookie，名称为"CookieCount"，值为"1"（thisCookie = new Cookie("CookieCount", "1")），并指定了该Cookie的最大寿命为10秒钟（setMaxAge(10)），然后将该Cookie发送给客户端（addCookie()）。如果Cookie已经存在，就将Cookie的值加1之后再发送给客户端。

    这样，如果客户端第一次访问CookieCounter Servlet，或者两次访问之间的时间间隔超过了10秒，就将看到如图14-8（a）所示的输出结果。如果客户端在Cookie的生命周期结束之前连续访问该Servlet，则Cookie的值将不断增加。如图14-8（b）所示的就是在10秒钟内连续访问两次Servlet时的输出结果。

from: http://www.jspcn.net/htmlnews/11242052102341354.html

Java NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。

Java NIO出现不只是一个技术性能的提高，你会发现网络上到处在介绍它，因为它具有里程碑意义，从JDK1.4开始，Java开始提高性能相关的功能，从而使得Java在底层或者并行分布式计算等操作上已经可以和C或Perl等语言并驾齐驱。

如果你至今还是在怀疑Java的性能，说明你的思想和观念已经完全落伍了，Java一两年就应该用新的名词来定义。从JDK1.5开始又要提供关于线程、并发等新性能的支持，Java应用在游戏等适时领域方面的机会已经成熟，Java在稳定自己中间件地位后，开始蚕食传统C的领域。

本文主要简单介绍NIO的基本原理，在下一篇文章中，将结合Reactor模式和著名线程大师Doug Lea的一篇文章深入讨论。

NIO主要原理和适用。

NIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知的socketchannel告诉Selector,我们接着做别的事情，当有事件发生时，他会通知我们，传回一组SelectionKey,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后，我们从这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。

Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生，比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。

了解了这个基本原理，我们结合代码看看使用，在使用上，也在分两个方向，一个是线程处理，一个是用非线程，后者比较简单，看下面代码：

这是一个守候在端口9000的noblock server例子，如果我们编制一个客户端程序，就可以对它进行互动操作，或者使用telnet 主机名　90000 可以链接上。

通过仔细阅读这个例程，相信你已经大致了解NIO的原理和使用方法，下一篇，我们将使用多线程来处理这些数据，再搭建一个自己的Reactor模式。

from: http://www.jdon.com/concurrent/nio%D4%AD%C0%ED%D3%A6%D3%C3.htm

protectedvoid doGet(HttpServletRequest request, HttpServletResponse response)
{
  response.sendRedirect("/anotherURL");
}

protectedvoid doGet(HttpServletRequest request, HttpServletResponse response)
{
  ServletContext context = getServletContext();
  RequestDispatcher dispatcher = context.getRequestDispatcher("/anotherURL");
  dispatcher.forward(request, response);
}

1.Servlet的生命周期

Servlet的生命周期是由Web容器负责的,当客户端第一次请求Servlet 时,容器负责初始化Servlet,也就是实例化这个Servlet类.以后这个实例就负责客户端的请求,一般不会再实例化其他Servlet类,也就是有多个线程在使用这个实例.Servlet之所以比CGI效率高就是因为Servlet是多线程的.如果该Servlet被声明为单线程模型的话,容器就会维护一个实例池,那么将存在多个实例.

2.Servlet的线程安全

Servlet规范已经声明Servlet不是线程安全的,所以在开发Servlet的时候要注要这个问题.这里以一个现实的模型来说明问题,先定义一个Servlet类,再定义一个SmulateMultiThread类和WebContainer类.

import javax.servlet.http.HttpServlet;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;

//该类模拟多线程Servlet的情况

public class SmulateMultiThread implements Runnable{

public SmulateMultiThread() {

}

public static void main(String[] args) {

//处理100个请求

for(int i=0;i<100;i++)

{

new Thread(new SmulateMultiThread()).start();

}

}

public void run() {

HttpServletRequest request=null;

HttpServletResponse response=null;

try {

WebContainer.getServlet().doGet(request, response);

}

catch (IOException ex) {

}

catch (ServletException ex) {

}

}

}

//这是一个Servlet类

class UnsafeServlet extends HttpServlet{

private String unsafe;

public void init() throws ServletException {

}

//Process the HTTP Get request

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

unsafe=Thread.currentThread().getName();

System.out.println(unsafe);

}

}

//这个是容器类

class WebContainer{

private static UnsafeServlet us=new UnsafeServlet();

public static UnsafeServlet getServlet(){

return us;

}

}

输出了100不同的线程名称,如果有100个请求同时被这个Servlet处理的话,那么unsafe就可能有100种去值,最后客户端将得到错误的值.比如客户1请求的线程名为thread-1,但是返回给他的可能是thread- 20.表现在现实中就是,我登陆的用户名是user1,登陆后变成了user2.

那么怎样才能是Servlet安全呢,凡是多个线程可以共享的就不要使用(实例变量+类变量),就这么简单.也可以使用synchronized同步方法,但是这样效率不高,还可以使用单线程模型,这样的话效率就更低了,100个请求同时来的时候就要实例化100个实例.

方法中的临时变量是不会影响线程安全的,因为他们是在栈上分配空间,而且每个线程都有自己私有的栈空间.

3.JSP中线程安全

JSP的本质是Servlet,所有只要明白了Servlet的安全问题,JSP的安全问题应该很容易理解.使用<%! %>声明的变量是Servlet的实例变量,不是线程安全的,其他都是线程安全的.

<%! String unsafeVar; %>//不是线程安全的

<% String safeVar; %>// 线程安全的

总结:线程安全问题主要是由实例变量造成的,不管在Servlet还是JSP,或者在Struts的Action里面,不要使用实例变量,任何方法里面都不要出现实例变量,你的程序就是线程安全的.

from: http://www.dwww.cn/new/200610111726432966.html

JSP默认是以多线程方式执行的，这是JSP与 ASP ， PHP ， Perl 等脚本语言不一样的地方，也是它的优势之一，但如果不注意多线程中的同步问题，会使所写的JSP程序有难以发现的错误。下面以一个例子说明JSP中的多线程问题及解决方法。

一、JSP的中存在的多线程问题：

当客户端第一次请求某一个JSP文件时，服务端把该JSP编译成一个CLASS文件，并创建一个该类的实例，然后创建一个线程处理CLIENT端的请求。如果有多个客户端同时请求该JSP文件，则服务端会创建多个线程。每个客户端请求对应一个线程。以多线程方式执行可大大降低对系统的资源需求,提高系统的并发量及响应时间.对JSP中可能用的的变量说明如下:

实例变量

实例变量是在堆中分配的,并被属于该实例的所有线程共享，所以不是线程安全的.

JSP系统提供的8个类变量

JSP中用到的OUT,REQUEST,RESPONSE,SESSION,CONFIG,PAGE,PAGECONXT是线程安全的,APPLICATION在整个系统内被使用,所以不是线程安全的.

局部变量

局部变量在堆栈中分配,因为每个线程都有它自己的堆栈空间,所以是线程安全的.

静态类

静态类不用被实例化,就可直接使用,也不是线程安全的.

外部资源:

在程序中可能会有多个线程或进程同时操作同一个资源(如:多个线程或进程同时对一个文件进行写操作).此时也要注意同步问题.

二、下面的例子存在的多线程问题：

<%@ page import="

Java x.naming.*,

java.util.*,

java.sql.*,

Web logic.common.*

" %>

<%

String name

String product;

long quantity;

name=request.getParameter("name");

product=request.getParameter("product");

quantity=request.getParameter("quantity"); /*(1)*/

savebuy();

%>

<%!

public void savebuy()

{

/*进行 数据库 操作，把数据保存到表中*/

try {

Properties props = new Properties();

props.put("user","scott");

props.put("password","tiger");

props.put("server","DEMO");

Driver myDriver = (Driver) iver").newInstance();

conn = myDriver.connect(" JDBC :weblogic: Oracle ", props);

stmt = conn.createStatement();

String inssql = "insert into buy(empid, name, dept) values (?, ?, ?,?)";

stmt = conn.prepareStatement(inssql);

stmt.setString(1, name);

stmt.setString(2, procuct);

stmt.setInt(3, quantity);

stmt.execute();

}

catch (Exception e)

{

System.out.println("SQLException was thrown: " + e.getMessage());

}

finally //close connections and {

try {

if(stmt != null)

stmt.close();

if(conn != null)

conn.close();

} catch (SQLException sqle) {

System.out.println("SQLException was thrown: " + sqle.getMessage());

}

}

}

%>

上面的程序模拟网上购物中的一部分,把用户在浏览器中输入的用户名,购买的物品名称,数量保存到表BUY中。在savebuy()函数中用到了实例变量,所以它不是线程安全的.因为:程序中的每一条语句都不是原子操作,如name= request.getParameter("name");在执行是会对应多个机器指令,在任何时候都可能因系统调度而转入睡眠状态,让其他的线程继续执行.如果线程A在执行到(1)的时候转入睡眠状态,线程B开始执行并改变QUANTITY的值,那么当又到A执行时,它会从调用savebuy()函数开始执行，这样它保存到表中的QUANTITY是被线程B改过的值,那么线程A对应的用户所实际购买的数量与保持到表中的数据不一致.这是个很严重的问题.

三、解决方法

采用单线程方式

在该JSP文件中加上: ,使它以单线程方式执行,这时，仍然只有一个实例，所有客户端的请求以串行方 式执行。这样会降低系统的性能.

对函数savebuy()加synchronized进行线程同步,该JSP仍然以多线程方式执行，但也会降低系统的性能

public synchronized void savebuy()

{

......

}

采用局部变量代替实例变量,函数savebuy()声明如下:

因为在savebuy()中使用的是传给他的形参,是在堆栈中分配的,所以是线程安全的.

public void savebuy(String name,String product, int quantity)

{

......

}

调用方式改为:

<%

String name

String product;

long quantity;

name=request.getParameter("name");

product=request.getParameter("product");

quantity=request.getParameter("quantity");

savebuy(name,product,quantity)

%>

如果savebuy的参数很多,或这些数据要在很多地方用到,也可声明一个类,并用他做参数,如:

public class buyinfo

{

String name;

String product;

long quantity;

}

public void savebuy(buyinfo info)

{

......

}

调用方式改为:

<%

buyinfo userbuy = new buyinfo();

userbuy.name=request.getParameter("name");

userbuy.product=request.getParameter("product");

userbuy.quantity=request.getParameter("quantity");

savebuy(userbuy);

%>

所以最好是用3,因为1,2会降低系统的性能.

多线程问题一般只有在在大并发量访问时，才有可能出现，并且很难重复出现，所以应在编程时就时刻注意。

from: http://java.ccidnet.com/art/3737/20030321/530503_1.html

　　J2EE并非一个产品，而是一系列的标准。市场上可以看到很多实现了J2EE的产品，如BEA WebLogic，IBM WebSphere以及 开源 的 JBoss 等等。

      J2EE，是sun公司提出的一个标准，符合这个标准的产品叫"实现"；其中你下载的sun公司的j2ee开发包中就有一个这样的"实现"，而jboss，weblogic，websphere都是j2ee标准的一个"实现"。由于jboss，weblogic，websphere自身带有j2ee的api，所以可以不使用sun的j2ee实现。

一. J2EE的概念

      目前，Java 2平台有3个版本，它们是适用于小型设备和智能卡的Java 2平台Micro版（Java 2 Platform Micro Edition，J2ME）、适用于桌面系统的Java 2平台标准版（Java 2 Platform Standard Edition，J2SE）、适用于创建服务器应用程序和服务的Java2平台企业版（Java 2 Platform Enterprise Edition，J2EE）。

      J2EE是一种利用Java 2平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。J2EE技术的基础就是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如"编写一次、随处运行"的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中保护数据的安全模式等等，同时还提供了对 EJB（Enterprise JavaBeans）、Java Servlets API、JSP（Java Server Pages）以及XML技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。

      J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。

二. J2EE的优势

     J2EE为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制:
      保留现存的IT资产: 由于企业必须适应新的商业需求，利用已有的企业信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样，一个以渐进的（而不是激进的，全盘否定的）方式建立在已有系统之上的服务器端平台机制是公司所需求的。J2EE架构可以充分利用用户原有的投资，如一些公司使用的BEA Tuxedo、IBM CICS, IBM Encina,、Inprise VisiBroker 以及Netscape Application Server。这之所以成为可能是因为J2EE拥有广泛的业界支持和一些重要的'企业计算'领域供应商的参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可移植的J2EE领域的升级途径。由于基于J2EE平台的产品几乎能够在任何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。

      高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:

      状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。
      持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。
      分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。
      支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。
      可伸缩性: 企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。（这是NT服务器所望尘莫及的）J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。
      稳定的可用性: 一个服务器端平台必须能全天候运转以满足公司客户、合作伙伴的需要。因为INTERNET是全球化的、无处不在的，即使在夜间按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。J2EE部署到可靠的操作环境中，他们支持长期的可用性。一些J2EE部署在WINDOWS环境中，客户也可选择健壮性能更好的操作系统如Sun Solaris、IBM OS/390。最健壮的操作系统可达到99.999%的可用性或每年只需5分钟停机时间。这是实时性很强商业系统理想的选择。

三. J2EE 的四层模型

      J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，sun设计J2EE的初衷正是为了解决两层模式(client/server)的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议――通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE 的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构:

      运行在客户端机器上的客户层组件
      运行在J2EE服务器上的Web层组件
      运行在J2EE服务器上的业务逻辑层组件
      运行在EIS服务器上的企业信息系统(Enterprise information system)层软件

      J2EE应用程序组件
      J2EE应用程序是由组件构成的.J2EE组件是具有独立功能的软件单元，它们通过相关的类和文件组装成J2EE应用程序，并与其他组件交互。J2EE说明书中定义了以下的J2EE组件:
      应用客户端程序和applets是客户层组件.
      Java Servlet和JavaServer Pages(JSP)是web层组件.
      Enterprise JavaBeans(EJB)是业务层组件.

      客户层组件
      J2EE应用程序可以是基于web方式的,也可以是基于传统方式的.
      web 层组件J2EE web层组件可以是JSP 页面或Servlets.按照J2EE规范，静态的HTML页面和Applets不算是web层组件。

      正如下图所示的客户层那样，web层可能包含某些 JavaBean 对象来处理用户输入，并把
输入发送给运行在业务层上的enterprise bean 来进行处理。

      业务层组件
      业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要,由运行在业务层上的enterprise bean 进行处理. 下图表明了一个enterprise bean 是如何从客户端程序接收数据，进行处理(如果必要的话), 并发送到EIS 层储存的，这个过程也可以逆向进行。

      有三种企业级的bean: 会话(session) beans, 实体(entity) beans, 和 消息驱动(message-driven) beans. 会话bean 表示与客户端程序的临时交互. 当客户端程序执行完后, 会话bean 和相关数据就会消失. 相反, 实体bean 表示数据库的表中一行永久的记录. 当客户端程序中止或服务器关闭时, 就会有潜在的服务保证实体bean 的数据得以保存.消息驱动 bean 结合了会话bean 和 JMS的消息监听器的特性, 允许一个业务层组件异步接收JMS 消息.

      企业信息系统层
      企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划 (ERP), 大型机事务处理, 数据库系统,和其它的遗留信息系统. 例如，J2EE 应用组件可能为了数据库连接需要访问企业信息系统

      我们就J2EE的各种组件、服务和API，进行更加详细的阐述，看看在开发不同类型的企业级应用时，根据各自需求和目标的不同，应当如何灵活使用并组合不同的组件和服务。

· Servlet

      Servlet是Java平台上的CGI技术。Servlet在服务器端运行，动态地生成Web页面。与传统的CGI和许多其它类似CGI的技术相比，Java Servlet具有更高的效率并更容易使用。对于Servlet，重复的请求不会导致同一程序的多次转载，它是依靠线程的方式来支持并发访问的。

· JSP

      JSP(Java Server Page)是一种实现普通静态HTML和动态页面输出混合编码的技术。从这一点来看，非常类似Microsoft ASP、PHP等技术。借助形式上的内容和外观表现的分离，Web页面制作的任务可以比较方便地划分给页面设计人员和程序员，并方便地通过JSP来合成。在运行时态，JSP将会被首先转换成Servlet，并以Servlet的形态编译运行，因此它的效率和功能与Servlet相比没有差别，一样具有很高的效率。

· EJB

      EJB定义了一组可重用的组件：Enterprise Beans。开发人员可以利用这些组件，像搭积木一样建立分布式应用。在装配组件时，所有的Enterprise Beans都需要配置到EJB服务器(一般的Weblogic、WebSphere等J2EE应用服务器都是EJB服务器)中。EJB服务器作为容器和低层平台的桥梁管理着EJB容器，并向该容器提供访问系统服务的能力。所有的EJB实例都运行在EJB容器中。EJB容器提供了系统级的服务，控制了EJB的生命周期。EJB容器为它的开发人员代管了诸如安全性、远程连接、生命周期管理及事务管理等技术环节，简化了商业逻辑的开发。EJB中定义了三种Enterprise Beans：

◆ Session Beans

◆ Entity Beans

◆ Message-driven Beans

· JDBC

      JDBC(Java Database Connectivity，Java数据库连接)API是一个标准SQL(Structured Query Language，结构化查询语言)数据库访问接口，它使数据库开发人员能够用标准Java API编写数据库应用程序。JDBC API主要用来连接数据库和直接调用SQL命令执行各种SQL语句。利用JDBC API可以执行一般的SQL语句、动态SQL语句及带IN和OUT参数的存储过程。Java中的JDBC相当与Microsoft平台中的ODBC(Open Database Connectivity)。

· JMS

      JMS(Java Message Service，Java消息服务)是一组Java应用接口，它提供创建、发送、接收、读取消息的服务。JMS API定义了一组公共的应用程序接口和相应语法，使得Java应用能够和各种消息中间件进行通信，这些消息中间件包括IBM MQ-Series、Microsoft MSMQ及纯Java的SonicMQ。通过使用JMS API，开发人员无需掌握不同消息产品的使用方法，也可以使用统一的JMS API来操纵各种消息中间件。通过使用JMS，能够最大限度地提升消息应用的可移植性。 JMS既支持点对点的消息通信，也支持发布/订阅式的消息通信。

· JNDI

      由于J2EE应用程序组件一般分布在不同的机器上，所以需要一种机制以便于组件客户使用者查找和引用组件及资源。在J2EE体系中，使用JNDI(Java Naming and Directory Interface)定位各种对象，这些对象包括EJB、数据库驱动、JDBC数据源及消息连接等。JNDI API为应用程序提供了一个统一的接口来完成标准的目录操作，如通过对象属性来查找和定位该对象。由于JNDI是独立于目录协议的，应用还可以使用JNDI访问各种特定的目录服务，如LDAP、NDS和DNS等。

· JTA

      JTA(Java Transaction API)提供了J2EE中处理事务的标准接口，它支持事务的开始、回滚和提交。同时在一般的J2EE平台上，总提供一个JTS(Java Transaction Service)作为标准的事务处理服务，开发人员可以使用JTA来使用JTS。

· JCA

      JCA(J2EE Connector Architecture)是J2EE体系架构的一部分，为开发人员提供了一套连接各种企业信息系统(EIS，包括ERP、SCM、CRM等)的体系架构，对于EIS开发商而言，它们只需要开发一套基于JCA的EIS连接适配器，开发人员就能够在任何的J2EE应用服务器中连接并使用它。基于JCA的连接适配器的实现，需要涉及J2EE中的事务管理、安全管理及连接管理等服务组件。

· JMX

      JMX(Java Management Extensions)的前身是JMAPI。JMX致力于解决分布式系统管理的问题。JMX是一种应用编程接口、可扩展对象和方法的集合体，可以跨越各种异构操作系统平台、系统体系结构和网络传输协议，开发无缝集成的面向系统、网络和服务的管理应用。JMX是一个完整的网络管理应用程序开发环境，它同时提供了厂商需要收集的完整的特性清单、可生成资源清单表格、图形化的用户接口；访问SNMP的网络API；主机间远程过程调用；数据库访问方法等。

· JAAS

      JAAS(Java Authentication and Authorization Service)实现了一个Java版本的标准Pluggable Authentication Module(PAM)的框架。JAAS可用来进行用户身份的鉴定，从而能够可靠并安全地确定谁在执行Java代码。同时JAAS还能通过对用户进行授权，实现基于用户的访问控制。

· JACC

      JACC(Java Authorization Service Provider Contract for Containers)在J2EE应用服务器和特定的授权认证服务器之间定义了一个连接的协约，以便将各种授权认证服务器插入到J2EE产品中去。

· JAX-RPC

      通过使用JAX-RPC(Java API for XML-based RPC)，已有的Java类或Java应用都能够被重新包装，并以Web Services的形式发布。JAX-RPC提供了将RPC参数(in/out)编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使用EJB(Enterprise JavaBeans)的商业应用而言，同样可以使用JAX-RPC来包装成Web服务，而这个Web Servoce的WSDL界面是与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web服务的部署和实现，对Web服务的开发人员而言，SOAP/WSDL变得透明，这有利于加速Web服务的开发周期。

· JAXR

      JAXR（Java API for XML Registries）提供了与多种类型注册服务进行交互的API。JAXR运行客户端访问与JAXR规范相兼容的Web Servcices，这里的Web Services即为注册服务。一般来说，注册服务总是以Web Services的形式运行的。JAXR支持三种注册服务类型：JAXR Pluggable Provider、Registry-specific JAXR Provider、JAXR Bridge Provider(支持UDDI Registry和ebXML Registry/Repository等)。

· SAAJ

      SAAJ(SOAP with Attachemnts API for Java)是JAX-RPC的一个增强，为进行低层次的SOAP消息操纵提供了支持。

四. J2EE 的结构

      这种基于组件，具有平台无关性的J2EE 结构使得J2EE 程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE 服务器以容器的形式为所有的组件类型提供后台服务. 因为你不用自己开发这种服务, 所以你可以集中精力解决手头的业务问题.

      容器和服务

      容器设置定制了J2EE服务器所提供得内在支持，包括安全，事务管理，JNDI(Java Naming and Directory Interface)寻址,远程连接等服务，以下列出最重要的几种服务：

      J2EE安全(Security)模型可以让你配置 web 组件或enterprise bean ,这样只有被授权的用户才能访问系统资源. 每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。你应在enterprise bean的布置描述中声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全性的规则。

      J2EE 事务管理（Transaction Management）模型让你指定组成一个事务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单元. 当客户端激活一个enterprise bean中的方法，容器介入一管理事务。因有容器管理事务，在enterprise bean中不必对事务的边界进行编码。要求控制分布式事务的代码会非常复杂。你只需在布置描述文件中声明enterprise bean的事务属性，而不用编写并调试复杂的代码。容器将读此文件并为你处理此enterprise bean的事务。

      JNDI 寻址(JNDI Lookup)服务向企业内的多重名字和目录服务提供了一个统一的接口,这样应用程序组件可以访问名字和目录服务.

      J2EE远程连接（Remote Client Connectivity）模型管理客户端和enterprise bean间的低层交互. 当一个enterprise bean创建后, 一个客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样.

      生存周期管理（Life Cycle Management）模型管理enterprise bean的创建和移除,一个enterprise bean在其生存周期中将会历经几种状态。容器创建enterprise bean，并在可用实例池与活动状态中移动他，而最终将其从容器中移除。即使可以调用enterprisebean的create及remove方法，容器也将会在后台执行这些任务。

五、企业级应用示例

      下面我们通过假设一个企业应用的J2EE实现，来了解各种组件和服务的应用。假设应用对象是计算机产品的生产商/零售商的销售系统，这个销售系统能够通过自己的网站发布产品信息，同时也能将产品目录传送给计算机产品交易市场。销售系统能够在线接受订单(来自自己的Web网站或者来自计算机产品交易市场)，并随后转入内部企业管理系统进行相关的后续处理。

      参见图1，这个企业应用可以这种方式架构。该企业应用的核心是产品目录管理和产品定购管理这两个业务逻辑，使用EJB加以实现，并部署在EJB容器中。由于产品目录和定购信息都需要持久化，因此使用JDBC连接数据库，并使用JTA来完成数据库存取事务。

Summary

By Jeff McAffer, IBM OTI Labs
January 27, 2004

Preamble

In this document the terms deprecated and obsolete are used to mean that the code is not part of the Eclipse runtime story going forward. For Eclipse 3.0 this code is still a full-fledged member of the API and is fully supported.

The new runtime is 99% binary compatible with the original Eclipse runtime. That is, with the exception of the cases listed above, most existing plug-ins will continue to run unchanged.

Having said that, there are costs associated with the compatibilty layer and the full power of the new runtime is not available to legacy plug-ins. Plug-in developers interested in additional performance and function should consider adopting the new APIs and removing their dependence on the compatibility layer. Compatibility code shows up in three places:

• org.eclipse.core.boot - entire plug-in are legacy
• org.eclipse.core.runtime.compatibility - entire plug-in are legacy
• org.eclipse.core.runtime - various classes and methods are legacy

The text below gives more detail on the which classes and methods are present for compatibility purposes as well as guidance on how to update your plug-in should you choose to.

Plug-ins and bundles

The Eclipse runtime has been refactored into two parts; classloading and prerequisite management, and extension/extension-point management. This split allows for natural/seamless adoption of the OSGi framework specification for classloading and prerequisite management. This in turn enables a range of new capabilities in the runtime from dynamic plug-in install/update/uninstall to security and increased configurability.

While we continue to talk about plug-ins, in the new runtime a plug-in is really a bundle plus some extensions and extension-points. The term bundle is defined by the OSGi framework specification and refers to a collection of types and resources and associated inter-bundle prerequisite information. The extension registry (and related types) is the new form of the plug-in registry (and related types) and details only extension and extension-point information. By-in-large the extension registry API is the same as the relevant plug-in registry API (for more information see Registries).

In the Eclipse 2.x runtime, the plug-in object has a number of roles and responsibilities:

• Lifecycle - The Plugin class implements method such as startup() and shutdown(). The runtime uses these methods to signal the plug-in that someone is interested in the function it provides. In response, plug-ins typically do a combination of:
  • Registration - Hook various event mechanisms (e.g., register listeners) and otherwise make their presence known in the system (e.g., start needed threads).
  • Initialization - Initialize or prime their data structures and load models so they are ready for use.
• Plug-in global data/function - While never explicitly put forth for this role, in common practice plug-in classes have become a place to hang data and function which is effectively global to the plug-in itself. In some cases this data/function is API in others it is internal. For example, the UI plug-in exposes as API methods such as getDialogSettings() and getWorkbench().
• Context - The standard Plugin class provides access to various runtime-provided function such as preferences and logging.

In the Eclipse 3.0 runtime picture, these roles and responsibilities are factored into distinct objects.

Bundle

Bundles are the OSGi unit of modularity. There is one classloader per bundle and Eclipse-like inter-bundle class loading dependency graphs can be constructed. Bundles have lifecycle for start and stop and the OSGi framework broadcasts bundle related events (e.g., install, resolve, start, stop, uninstall, ...) to interested parties. Unlike the Eclipse Plugin class, the OSGi Bundle class is not extensible. That is, developers do not have the opportunity to define their own bundle class.

BundleActivator

BundleActivator is an interface defined by the OSGi framework. Each bundle can define a bundle activator class much like a plug-in can define its Plugin class. This class is instantiated by the framework and used to implement the start() and stop() lifecycle processing. There is a major difference however in the nature of this lifecycle processing. In Eclipse it is common (though not recommended) to have the Plugin classes do both initialization and registration. In OSGi activators must only do registration. Doing large amounts of initialization (or any other work) in BundleActivator.start() threatens the liveness of the system.

BundleContext

BundleContexts are the OSGi mechanism for exposing general system function to individual bundles. Each bundle has a unique and private instance of BundleContext which they can use to access system function (e.g., getBundles() to discover all bundles in the system).

Plugin

The new Plugin is very much like the original Eclipse Plugin class with the following exceptions: Plugin objects are no longer a) required or b) managed by the runtime and various methods have been deprecated (see below). As such, Plugin continues to provide context access. It is essentially a convenience mechanism providing a host of useful function and mechanisms but is no longer absolutely required. Much of the function provided there is also available on the Platform class in the runtime.

Plugin also implements BundleActivator. This recognizes the convenience of having one central object representing the lifecycle and semantic of a plug-in. Note that this does not however sanction the eager initialization of data structures that is common in plug-ins today. We cannot stress enough that plug-ins can be activated because a somewhat peripheral class was referenced during verification of a class in some other plug-in. That is, just because your plug-in has been activated does not necessarily mean that its function is needed. Note also that you are free to define a different BundleActivator class or not have a bundle activator at all.

The steps required to port a 2.x Plugin class to Eclipse 3.0 depends on what the class is doing. As outlined above, most startup lifecycle work falls into one of the following categories:

Initialization

Datastructure and model initialization is quite often done in Plugin.startup(). The natural/obvious mapping would be to do this work in a BundleActivator.start(), that is to leave the function on Plugin. This is strongly discouraged. As with 2.x plug-ins, 3.0 plug-ins/bundles may be started for many different reasons in many different circumstances.
An actual example from Eclipse 2.0 days illuminates this case. There was a plug-in which initialized a large model requiring the loading of some 11MB of code and many megabytes of data. There were quite common usecases where this plug-in was activated to discover if the project icon presented in the navigator should be decorated with a particular markup. This test did not require any of the initialization done in startup() but yet all users, in all usecases had to pay the memory and time penalty for this eager initialization.
The alternative approach is to do such initialization in a classic lazy style. For example, rather than having models initialized when the plug-in/bundle is activated, do it when they are actually needed (e.g., in a centralized model accessor method). For many usecases this will amount to nearly the same point in time but for other scenarios this approach will defer initialization (perhaps indefinitely). We recommend taking time while porting 2.1 plug-ins to reconsider the initialization strategy used.

Registration

Plug-in startup is a convenient time to register listeners, services etc. and start background processing threads (e.g., listening on a socket). Plugin.start() may a reasonable place to do this work. It may also make sense to defer until some other trigger (e.g., the use of a particular function or data element).

Plug-in global data

Your Plugin class can continue to play this role. The main issue is that Plugin objects are no longer globally accessible via a system-managed list. In Eclipse 2.x you could discover any plug-in's Plugin ojbect via the plug-in registry. This is no longer possible. In most circumstances this type of access is not required. Plugins accessed via the registry are more typically used as generic Plugins rather than calling domain-specific methods.

Registries and the plug-in model

In the new runtime there is a separation between the information and structures needed to execute a plug-in and that related to a plug-in's extensions and extension points. The former is defined and managed by the OSGi framework specification. The latter are Eclipse-specific concepts and are added by they Eclipse runtime code. Accordingly, the original plug-in registy and related objects have been split into OSGi bundles and the Eclipse extension registry.

The parts of IPluginRegistry dealing with execution specification (e.g., IPluginDescriptor, ILibrary, IPrequisite) have been deprecated and the remaining parts related to extensions and extension point have been moved to IExtensionRegistry. Further, the so-called model objects related to the plug-in registry as a whole are now deprecated. These types were presented and instantiated by the runtime primarily to support tooling such as PDE. Unfortunately, it was frequently the case that the level of information needed exceeded the runtime's capabilities or interests (e.g., remembering line numbers for plugin.xml elements) and in the end, the potential consumers of the runtime's information had to maintain their own structures anyway.

In the new runtime we have re-evaluated the facilities provided by the runtime and now provide only those which are either essential for runtime execution or are extraordinarily difficult for others to do. As mentioned above, the plug-in registry model objects have been deprecated as has the plug-in parsing API. The new extensions registry maintains the essential extension-related information. A new state (see org.eclipse.osgi.service.resolver.State and friends) structure represents and allows the manipulation of the essential execution-related information.

Legacy code

org.eclipse.core.boot.BootLoader (class)

BootLoader has been completely deprecated and merged with org.eclipse.core.runtime.Platform since it no longer made sense to have a split between boot and runtime. Note that in fact, the org.eclipse.core.boot plug-in has been broken up and all its code moved to either the new runtime or the compatibility layer.

org.eclipse.core.boot.IPlatformConfiguration (class)

IPlatformConfiguration has always been a type defined by and for the Ecliipse Install/Update component. With the reorganization of the runtime we are able to repatriate this type to its rightful home. This class remains largely unchanged and has been repackaged as org.eclipse.update.configurator.IPlatformConfiguration. The compatibility layer retains a deprecated copy of the original class.

org.eclipse.core.boot.IPlatformRunnable (class)

org.eclipse.core.runtime.IExtension
org.eclipse.core.runtime.IExtensionPoint (methods)

• getDeclaringPlugin()
  • This method (on both classes) gives an upward link to the plug-in which declares the extension or extension-point (respectively). The new registry model separates the execution aspects of plug-ins from the extension/extension-point aspects and no longer contains IPluginDescriptors. Users of this API should consider the new method getParentIdentifier() found on both IExtension and IExtensionPoint. The returned value can be used directly or as a key in the compatibility IPluginRegistry or the OSGi framework's API for bundle discovery (e.g., BundleContext.getBundles(String) <XXX point to the Platofrm method>).

org.eclipse.core.runtime.ILibrary (class)

In the original runtime, ILibrary is a representation of execution related attributes. In the new runtime these are now handled by OSGi. While it is possible to maintain some of the API for legacy plug-ins, it is not possible to do so for OSGi-based plug-ins/bundles. Users of ILibrary should consider using Bundle.getHeader(Constants.BUNDLE_CLASSPATH) and processing the results using the ManifestElement helper class.

org.eclipse.core.runtime.IPrerequisite (class)

In the original runtime, IPrerequisite is a representation of execution related attributes. In the new runtime these are now handled by OSGi. While it is possible to maintain some of the API for legacy plug-ins, it is not possible to do so for OSGi-based plug-ins/bundles. Users of IPrerequiste should consider using Bundle.getHeader(Constants.IMPORT_PACKAGE) or Bundle.getHeader(Constants.REQUIRE_BUNDLE) and processing the results using the ManifestElement helper class.

org.eclipse.core.runtime.Platform (methods)

• getPlugin(String)
  • In the new runtime, Plugin objects are no longer managed by the runtime and so cannot be accessed via this method. Use <XXX tentative> Platform.getBundle(String) instead. Note however that this returns only a generic Bundle object. Those wishing to use domain-specific function on a particular Plugin object must arrange for access with the plug-in in question. This is typically done via a singleton pattern (e.g., ResourcesPlugin.getDefault()).
• getPluginRegistry()
  • The plug-in registry object has been deprecated. If you are looking for the registry of extensions and extension points use Platform.getExtensionRegistry(). If you are looking to find the static and generic representation of a plug-in, consider using <XXX tentative> Platform.getBundle(String).

org.eclipse.core.runtime.Plugin (methods)

• Plugin(IPluginDescriptor)
  • The Plugin object is no longer created or managed by the runtime and IPluginDescriptor is deprecated. Plugin class implementors may choose to use their Plugin as a bundle activator in which case they must implement (allow for) the default constructor. Users wishing to have a Plugin class but not use it as the bundle activator need to implement the appropriate constructor which at a minimum takes the BundleContext to be associated with the plug-in.
• getPluginDescriptor()
  • IPluginDescriptor is now deprecated. Users of this method are looking for
    • extension/extension point information: go directly to org.eclipse.core.runtime.IExtensionRegistry
    • manifest information: get the bundle for the plug-in (getBundle()) and access its manifest headers as required.
• getPluginPreferences()
  • <xxx the preference mechanism is still in play>
• savePluginPreferences()
  • <xxx the preference mechanism is still in play>
• initializeDefaultPluginPreferences()
  • <xxx the preference mechanism is still in play>
• shutdown() and startup()
  • These methods have been replaced with the OSGi standard start() and stop() methods. Note that the new lifecycle methods are only automatically called if the defining Plugin class is registered as the bundle activator in a bundle manifest (MANIFEST.MF) file. See the header Bundle-Activator.
  • OSGi (and Eclipse) coding practices strongly recommend against doing or triggering significant work in the start() methods. Doing excessive work here can damage startup time as well as overall responsiveness.

org.eclipse.core.runtime.IPluginDescriptor (class)

Plug-in descriptors contain methods for a number of different purposes. These are outlined below as well as the steps for updating their uses.

extension-related (e.g., getExtensions())

Update such cases to use the IExtensionRegistry directly.

execution-related (e.g., find() and getPluginClassLoader())

Use the related methods found on org.eclipse.core.runtime.Platform

accessors (e.g., getLabel())

Get the bundle associated with the descriptor and access the appropriate manifest header fields.

org.eclipse.core.runtime.IPluginRegistry (class)

The contents of the plug-in registry, like the runtime, has been split into two parts, the execution-related and the extension-related. As such, the unified notion of a plug-in registry does not apply. Uses of the IPluginRegistry to discover extensions and extension-points are directly supported by nearly identical API on IExtensionRegistry. Uses of IPluginRegistry to discover IPluginDescriptors should be changed to use the appropriate OSGi structures. See the discussion related to IPluginDescriptor for more details.

org.eclipse.core.runtime.model (package)

All types in this package are now deprecated. See the discussion on registries for more information.

Updating plugin/fragment files

The new runtime is based on an implementation of the OSGi framework specification. The OSGi specification mandates the use of MANIFEST.MF files to define the execution of a plug-in. This conflicts with the Eclipse notion of plugin.xml as far as <runtime> and <requires> elements are concerned. The easiest way to update your plugin.xml or fragment.xml is to use the PDE Migration Tool (PDE Tools->Convert to OSGi bundle).

In certain situations the conversion tool is unable to correctly determine all of the packages provided by a plug-in. In particular, if a plug-in declares a library entry for say foo.jar but does not contain foo.jar, the converter is unable to generate the appropriate provides-package entries in the output manifest (this is done by analyzing the supplied jar which, in this case, is not present). Plug-in or fragments which are fully self-contained are converted correctly.

This tool extracts the execution-specific information from your plugin.xml and puts into the OSGi mandated META-INF/MANIFEST.MF file. All extension-related information is left in the plugin.xml. The manifest is a standard Java Jar file manifest. It contains specifications for the execution elements of our plug-in (e.g., classpath, prerequisites, ...). A table of frequent mapping is included below while the full OSGi specification has enumerates all pre-defined manifest headers.

The extension/extension-point related information continues to be detailed in the plugin.xml file however the following aspects of the plugin.xml DTD are being deprecated.

• all attributes on the <plugin> tag
• <runtime> and its <library> subelement
• <requires> and its <import> subelement

This leaves the plugin.xml containing only the <plugin>, <extension> and <extension-point> tags

Note also that the form of this content is not specific to a plug-ins vs. fragments. As a result, the fragment.xml file is being deprecated and renamed to plugin.xml with the outlined DTD changes. In most cases fragments do not supply extensions or extension-points so the bulk of the change required is done while moving to the MANIFEST.MF file and the fragment.xml file can be deleted.

The plugin.properties file continues to supply translations for the extension/extension-point information in plugin.xml and also supplies translations for various keys in the MANIFEST.MF.

The build.properties file remains unchanged.

from: http://dev.eclipse.org/viewcvs/index.cgi/platform-core-home/runtime/adoption.html?rev=1.5

GEF 概述

GEF 假定您拥有一个希望以图形方式显示和编辑的模型。为了做到这一点，GEF 提供了可在 Eclipse 工作台中任何地方使用的查看器（类型为 EditPartViewer ）。象 JFace 查看器一样，GEF 查看器是 SWT 控件上的适配器。但是它们的类似之处仅此而已。GEF 查看器基于模型-视图-控制器（model-view-controller，MVC）体系结构。

控制器作为视图和模型之间的桥梁（请参阅图 1）。每个控制器（即本文所谓的 EditPart）负责将模型映射到它的视图，也负责对模型进行更改。EditPart 还观察模型并更新视图，以反映模型状态中的变化。EditPart 是一种对象，用户将与这种对象进行交互。稍后将更详细地介绍 EditPart。

图 1. 模型-视图-控制器

GEF 提供了两种查看器类型：图形的和基于树的。每种查看器都主管一种不同类型的 视图。图形查看器使用了在 SWT 画布（Canvas）上绘制的 图形（figure）。图形是在 Draw2D 插件中定义的，该插件是 GEF 的一部分。TreeViewer 将 SWT 树和 TreeItem 用于其视图。

回页首

第 1 步. 选定自己的模型

GEF 对于模型一无所知。任何模型类型都可工作，只要它符合下面描述的特性。

模型中有什么？

所有东西都在模型中。模型是唯一会被持久存储和恢复的东西。您的应用程序应当将所有重要数据都存储在模型中。在编辑、撤销和重做的过程中，模型是唯一保持不变的。随着时间推移，将对图形和 EditPart 进行垃圾收集处理并重新创建。

当用户与 EditPart 交互时，EditPart 并不直接操作模型。而是创建一个封装了更改的 命令（Command）。命令可用来验证用户的交互，并且提供撤销和重做支持。

严格地说，命令概念上也是模型一部分。它们 本身并不是模型，而是一些方法，模型是由这些方法编辑的。命令用于执行用户的所有可撤销的更改。理论上，命令应当只了解模型。它们应当避免引用 EditPart 或图形。类似地，如果可能，命令应当避免调用用户界面（例如弹出式对话框）。

两个模型的故事

一个简单的 GEF 应用程序就是用于绘制图的编辑器。（这里 图只意味着图片，而不是类图等）图可以被建模成某些形状。一个形状可能具有位置、颜色等特性，并且可能是多个形状构成的一组结构。这里没有什么可惊讶的，并且前述需求也易于维护（请参阅图 2）。

图 2. 一个简单的模型

另一种常见的 GEF 应用程序是 UML 编辑器，例如类图编辑器。图中的一段重要信息就是 (x, y) 位置，类就出现在该位置上。根据前一节的介绍，您可能会以为模型必须将一个 类描述成具有 x和 y特性。大多数开发人员都不希望由于无意义的属性而“污染”其模型。在这类应用程序中，术语“业务”模型可用于指代基本模型，重要语义的详细信息存储在基本模型中。而特定于图的信息存储在“视图”模型（它指的是业务模型中某样东西的“视图”；在一个图中可多次查看某个对象）中。有时候这种划分甚至会反映在工作空间中，其中不同的资源可能被分别用来持久存储图和业务模型。甚至可能有多个图对应于同一个业务模型（请参阅图 3）。

图 3. 划分成业务模型和视图模型的模型

不管您的模型划分成了两个部分，还是划分成了多个资源，对于 GEF 而言这都是无关紧要的。术语模型用于指代整个应用程序模型。屏幕上的一个对象可能对应于模型中的多个对象。GEF 旨在允许开发人员方便地处理这类映射。

通知策略

对视图进行更新几乎总是由来自模型的通知而导致的。您的模型必须提供某种通知机制，该机制必须映射到您应用程序中相应的更新。而只读模型或不能进行通知的模型（例如文件系统或远程连接）可能是例外。

通知策略通常是分布式的（每对象）或集中式的（每域）。域通知器了解到对模型中任何对象的每次更改，然后将这些更改向域侦听器广播。如果您的应用程序使用了这种通知模型，您可能要为每个查看器添加一个域侦听器。当该侦听器接收到更改时，它将查找受影响的 EditPart，然后适当地重新分派该更改。如果您的应用程序使用了分布式通知，那么每个 EditPart 通常都将把自己的侦听器添加到任何一个影响它的模型对象。

回页首

第 2 步. 定义视图

下一步是决定将如何使用来自 Draw2D 插件的图形显示您的模型。某些图形可直接用来显示模型的某个对象。例如，Label 图形可用来显示 Image 和 String。有时候，通过组合多个图形、布局管理器和／或边框可以获得期望的结果。最后，您可能要编写自己的图形实现，该实现以特定于您应用程序的方式绘图。

有关组合或实现图形和布局的更多信息可在 Draw2D 开发人员指南中找到，该指南包含在 GEF SDK 中。

在和 GEF 一起使用 Draw2D 时，通过遵循下列方针，可以使您的项目更便于管理，并且可以更灵活地更改需求：

• 不要从头做起。您可以组合所提供的布局管理器以呈现大多数东西。请考虑使用工具栏布局（在垂直或水平方向上）和边框布局的组合来组合多个图形。只有在万不得已时才编写自己的布局管理器。作为参考，请查看 GEF 中提供的调色板。该调色板是使用 Draw2D 中的许多标准图形和布局呈现的。
  
  
• 保持 EditPart 和图形之间“彻底”的分离。如果您的 EditPart 使用了几个图形、布局和／或边框的复合结构，那么请尽量对 EditPart 隐藏详细信息。让 EditPart 自己构建所有东西是可能的（但不是个好主意）。不过这样做并不会导致控制器和视图之间“彻底”分离。EditPart 非常熟悉图形结构，因此以类似的 EditPart 重用该结构是不可能的。此外，更改外观或结构可能会导致意想不到的错误。
  
  替代方法是，您应当编写自己的 Figure 子类，该子类掩藏了图形结构的详细信息。然后定义这个子类最少数量的 API，EditPart（控制器）用这些 API 来更新视图。这种实践（称为 关注分离（separation of concerns））可提高重用机会并使错误更少。
  
  
• 不要从图形引用模型或 EditPart。图形不应该具有对 EditPart 或模型的访问权。在某些情形中，EditPart 可能会将自己作为侦听器添加到图形，但是只会认为它是侦听器，而不是 EditPart。这种去耦合（de-coupling）实践也可以产生更多的重用机会。
  
  
• 使用内容窗格。有时候您拥有一个容器，该容器将包含其它图形元素，但是您需要在容器四周进行一些装饰。例如，一个 UML 类通常显示为框，其顶部标有类名，可能还有一些原型，而底部是为属性和方法保留的。通过组合多个图形可以做到这一点。第一个图形是类的标题框，而另一个图形被指派为 内容窗格。该图形将最终包含表示属性和方法的图形。稍后在编写 EditPart 实现时，并不一定要表明应该将内容窗格用作所有子元素的父元素。

回页首

第 3 步. 编写您的 EditPart - 控制器

接下来我们将利用控制器（即 EditPart）将模型和视图联接起来。该步骤在 GEF 中放置“框架”。所提供的类是抽象的，因此客户实际上必须编写代码。结果证明，生成子类不仅是人们熟悉的方法，而且可能也是将模型映射到视图最灵活和简单的方法。

所提供的用于生成子类的基本实现有三种。对于出现在树查看器中的 EditPart 使用 AbstractTreeEditPart 。图形查看器中的继承 AbstractGraphicalEditPart 和 AbstractConnectionEditPart 。本文将着重讨论图形 EditPart。相同的原理同样适用于树查看器。

EditPart 生命周期

在编写您的 EditPart 之前，了解它们来自哪里，以及当不再需要它们时怎样处理它们，这是有帮助的。每个查看器都配置有一个用于创建 EditPart 的工厂（factory）。当您设置查看器的内容时，通过提供表示该查看器输入的模型对象，可以做到这一点。输入通常是最顶部的模型对象，通过该对象可遍历其它所有对象。然后查看器可以使用自己的工厂来构造用于该输入对象的 内容 EditPart。之后，查看器中的每个 EditPart 将填充和管理其自己的子 EditPart（和连接 EditPart），当需要新的 EditPart 时，将委派给 EditPart 工厂，直到填充该查看器。当用户添加新的模型对象时，包含这些对象的 EditPart 将通过构造相应的 EditPart 做出响应。请注意，视图的构造与 EditPart 的构造是同时进行的。因此，构造每个 EditPart 并将它添加到它的父 EditPart 之后，视图（不管是图形还是树项）也会发生同样的过程。

一旦用户除去与某些 EditPart 对应的模型对象，就丢弃这些 EditPart。如果用户撤销了一个删除操作，那么用于表示被恢复对象而重新创建的 EditPart 与原先的 EditPart 是不同的。这就是为什么 EditPart 不能包含长期信息，以及为什么不应由命令引用的原因。

您的第一个 EditPart：内容 EditPart

您编写的第一个 EditPart 是对应于图本身的 EditPart。这个 EditPart 称为查看器的 内容。它对应于模型中最顶部的元素，并且其父元素为查看器的 根EditPart（请参阅图 4）。根通过提供各种图形层（例如连接层和句柄层等）以及可能会在查看器级别提供的视图缩放或其它功能，为内容打下基础。请注意，根的功能不依赖于任何模型对象，GEF 为根提供了几个现成的实现。

图 4. 查看器中的 EditPart

内容的图形不是很有趣，并且它通常只是一个空面板，该面板将包含图的子图。它的图形应该为不透明类型（opaque），并且应当利用布局管理器进行初始化，该布局管理器将对图的子图进行布局。但是，它将拥有结构。图的直系子图是由返回的子模型对象列表确定的。清单 1 显示了一个样本内容 EditPart，它创建了一个不透明类型的图形，后者将使用 XYLayout 定位其子图。

												
														public class DiagramContentsEditPart extends AbstractGraphicalEditPart {
    protected IFigure createFigure() {
        Figure f = new Figure();
        f.setOpaque(true);
        f.setLayoutManager(new XYLayout());
        return f;
    }

    protected void createEditPolicies() {
        ...
    }

    protected List getModelChildren() {
        return ((MyModelType)getModel()).getDiagramChildren();
    }
}

												
										

要确定图上的项，需要实现方法 getModelChildren() 。该方法返回子模型对象的列表（例如图中的节点）。超类将使用这个模型对象列表来创建对应的 EditPart。新创建的 EditPart 被添加到部件的子 EditPart 列表。这样又会将每个子 EditPart 的图形添加到示例图。缺省情况下，将返回一个空的列表，这表明没有子对象。

其它图形 EditPart

其余的 EditPart（表示图中的项）可能拥有要以图形方式显示的数据。它们可能还拥有自己的结构，例如连接或自己的子 EditPart。许多 GEF 应用程序利用由标签注明的图标之间的连接来描述这些图标。让我们假定您的 EditPart 将使用 Label 作为它的图形，并且您的模型提供了名称、图标以及与标签之间的连接。清单 2 显示了实现这种类型 EditPart 的第一次尝试。

												
														public class MyNodeEditPart extends AbstractGraphicalEditPart {
    protected IFigure createFigure() {
        return new Label();
    }
    protected void createEditPolicies() {
        ...
    }
    protected List getModelSourceConnections() {
        MyModel node = (MyModel)getModel();
        return node.getOutgoingConnections();
    }
    protected List getModelTargetConnections() {
        MyModel node = (MyModel)getModel();
        return node.getIncomingConnections();
    }
    protected void refreshVisuals() {
        MyModel node = (MyModel)getModel();
        Label label = (Label)getFigure();
        label.setText(node.getName());
        label.setIcon(node.getIcon());

        Rectangle r = new Rectangle(node.x, node.y, -1, -1);
        ((GraphicalEditPart) getParent()).setLayoutConstraint(this, label, r);
    }
}

												
										

这里覆盖了一个新方法 refreshVisuals() 。当需要利用来自模型的数据更新图形时，就调用该方法。在本案例中，模型的名称和图标被反映在标签中。但更为重要的是，该标签是通过将其布局约束传递给父元素来定位的。在内容 EditPart 中，我们使用了 XY 布局管理器。该布局使用 Rectangle 约束来确定在何处放置子图形。宽和高的值为“-1”，表明应当为该图提供理想的大小。

技巧 #1 决不要使用 setBounds(...) 方法来放置图形。使用诸如 XYLayout 之类的布局管理器确保会正确地更新滚动条。另外，XYLayout 还处理将相对约束转换成绝对位置的工作，并且可用它来将图形自动调整为理想的大小（换而言之，如果约束的宽和高为 -1）。

方法 refreshVisuals() 仅在 EditPart 初始化的过程中调用一次，并且决不会被再次调用。在响应模型通知时，应用程序负责根据需要再次调用 refreshVisuals() 以更新图形。要改进性能，您可能希望将每个模型属性的代码分解成其自己的方法（或者是一个带有“开关（switch）”的方法）。这样，当模型发出通知时，可以运行最少的代码以便只刷新那些发生更改的内容。

另一个有趣的区别是连接支持的代码。与 getModelChildren() 类似， getModelSourceConnections() 和 getModelTargetConnections() 应当返回表示节点之间连接的模型对象。超类在必要时创建对应的 EditPart，并将它们添加到源和目标连接 EditPart 列表。请注意，连接是由每端的节点引用的，而其 EditPart 只需创建一次。GEF 确保只创建一次连接，该工作是通过首先检查查看器中是否已经存在连接来完成的。

回页首

建立连接

编写连接 EditPart 实现没有太大的区别。首先生成 AbstractConnectionEditPart 的子类。跟前面一样，可以实现 refreshVisuals() ，以将属性从模型映射到图形。连接可能还拥有约束，尽管这些约束与前面的约束略有不同。这里，连接路由器使用约束来使连接转向（bend）。此外，连接 EditPart 的图形必须是 Draw2D Connection ，它引入了另一个需求：连接锚（connection anchor）。

连接必须由 ConnectionAnchor “锚定”在两端。因此，必须在连接 EditPart 中或在节点实现中表明使用哪些锚。缺省情况下，GEF 假定节点 EditPart 将通过实现 NodeEditPart 接口而提供锚。这样假定的一个原因是，锚的选择取决于各端上的节点正在使用的图形。连接 EditPart 不应了解节点正在使用的图形的任何内容。另一个原因是，当用户创建连接时，连接 EditPart 是不存在的，因此节点必须能够自己显示反馈。作为清单 2 的延续，我们在清单 3 中添加了必要的锚支持。

												
														public class MyNodeEditPart
    extends AbstractGraphicalEditPart
    implements NodeEditPart
{
    ...
    public ConnectionAnchor getSourceConnectionAnchor(ConnectionEditPart connection) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getSourceConnectionAnchor(Request request) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getTargetConnectionAnchor(ConnectionEditPart connection) {
        return new ChopboxAnchor(getFigure());
    }
    public ConnectionAnchor getTargetConnectionAnchor(Request request) {
        return new ChopboxAnchor(getFigure());
    }

    ...
}

												
										

技巧 #2 别忘记真正实现 NodeEditPart 接口。否则您的方法将永远不会被调用。

以连接（connection）为参数的方法是对现有连接 EditPart 设置锚时使用的方法。其它两个方法以请求（request）作为参数。这些方法是用户创建新连接时的编辑过程中使用的。对于本示例，所有情形都将返回 chopbox 锚。chopbox 锚只查找线与节点图形的边框相交的点。

实现连接 EditPart 是比较简单的。请注意，甚至无需创建图形，因为缺省的 PolylineConnection 创建适合于大多数场合（请参阅清单 4）。

												
														public class MyConnectionEditPart extends AbstractConnectionEditPart {
    protected void createEditPolicies() {
        ...
    }

    protected void refreshVisuals() {
        PolylineConnection figure = (PolylineConnection)getFigure();
        MyConnection connx = (MyConnection)getModel();
        figure.setForegroundColor(MagicHelper.getConnectionColor(connx));
        figure.setRoutingConstraint(MagicHelper.getConnectionBendpoints(connx));
    }
}

												
										

技巧 #3 最重要的是了解何时使用以及何时不使用 ConnectionEditPart。当用户可以选择某些东西并可与之进行交互的时候，就使用连接 EditPart。它可能与模型中的某个对象直接相关，并且通常可由自己删除。 如果您只是拥有一个需要绘制直线的节点或容器，那么只须用图形的 paint 方法绘制直线，或者组合一个图形，该图形包含 Polyline 图形。 连接始终都必须拥有源和目标。如果您需要一个连接，该连接可以在没有源或没有目标的情况下存在，那么比较好的方法是只继承 AbstractGraphicalEditPart ，并使用连接图形。

侦听模型

创建 EditPart 之后，它应该开始侦听来自模型的更改通知。由于 GEF 是与模型无关的，因此所有应用程序都必须添加自己的侦听器，并处理产生的通知。接收到通知时，处理程序可以调用某个提供的方法来强制进行一次刷新。例如，如果删除了一个子模型对象，那么调用 refreshChildren() 将导致对应的 EditPart 及其图形被除去。对于简单的属性更改，可以使用 refreshVisuals() 。正如我们前面提及的，可将该方法分解成几个部分，从而避免没有必要地更新每个显示的属性。

添加侦听器但却忘记除去它们是导致内存泄漏的常见原因。出于这个原因，添加和除去侦听器的地方应该在 API 中清晰地注明。您的 EditPart 必须继承 activate() ，以便添加稍后必须除去的任何侦听器。通过继承 deactivate() 可除去那些相同的侦听器。清单 5 显示了向节点 EditPart 实现添加的模型通知内容。

												
														public class MyNodeEditPart
extends AbstractGraphicalEditPart
    implements NodeEditPart, ModelListener
{
    ...

    public void activate() {
        super.activate();
        ((MyModel)getModel()).addModelListener(this);
    }

    public void deactivate() {
        ((MyModel)getModel()).removeModelListener(this);
        super.deactivate();
    }

    public void modelChanged(ModelEvent event) {
        if (event.getChange().equals("outgoingConnections"))
            refreshSourceConnections();
        else if (event.getChange().equals("incomingConnections"))
            refreshTargetConnections();
        else if (event.getChange().equals("icon")
          || event.getChange().equals("name"))
            refreshVisuals();
    }

    ...
}

												
										

编辑模型

到目前为止，我们已经讲解了如何创建 EditPart，它们如何创建自己的可视图（visual）以及当模型发生变化时它们如何自我更新。除此之外，EditPart 也是对模型进行更改的主要参与者。当命令的请求被发送给 EditPart 时就会发生这种情况。请求还用来要求 EditPart 显示诸如在鼠标拖动期间发生的反馈。EditPart 支持、阻止或忽略给定的请求。所支持或阻止的请求类型决定了 EditPart 的行为。

到目前为止，侧重点都是将模型的结构和特性映射到视图。结果表明，这基本上是您在 EditPart 类自身中所做的所有工作。其行为是由一组名为 EditPolicies 的可插入的助手类决定的。在所提供的示例中，我们忽略了方法 createEditPolicies() 。一旦您实现该方法，您就几乎已经完成了您的 EditPart。当然，您仍需要提供编辑策略，该策略知道如何修改您应用程序的模型。

因为编辑行为是可插入的，所以在开发各种 EditPart 实现时，可以根据将模型映射到视图和处理模型更新这种任务，来创建类层次结构。

回页首

第 4 步. 将所有内容组合在一起

现在，您已经完成了以图形方式显示您的模型所需的所有部分。对于最后的组装，我们将使用 IEditorPart 。但是，也可以在视图、对话框或者可以放置控件的几乎任何地方使用 GEF 的查看器。对于本步骤，您必须拥有自己的 UI 插件，它将为正在打开的资源定义编辑器和文件扩展名。可在同一个插件或一个不同的插件中定义您的模型。您还需要一个预填充的模型，因为目前还没有编辑功能。

提供样本模型数据的方法有几种。对于本示例而言，当编辑器打开时，我们将在代码中创建模型，从而忽略了文件的实际内容。要做到这一点，我们假定已经存在一个测试工厂。或者，您可以创建一个示例向导，该向导用数据对资源进行预填充（普通向导只创建空图）。最后，您可以利用文本编辑器以手工方式编写文档的内容。

既然您有了样本模型，那么让我们创建将显示模型的编辑器部件。有一种快速的方法，就是生成子类或复制 GEF 的 GraphicalEditor 。该类创建 ScrollingGraphicalViewer 的一个实例，并且构造一个画布来充当编辑器的控件。它是一个很方便的类，用来帮助您开始使用 GEF；一个可以正确工作的 Eclipse 编辑器需要考虑很多其它事情，例如不利的团队环境（pessimistic team environment）和要删除或移动资源等。

清单 6 显示了一个样本编辑器实现。有几个必须实现的抽象方法。出于本文所讨论范围的限制，我们将忽略模型持久性和标记。要让您的图出现在图形查看器中，您必须做两件事情。首先，利用自己的 EditPart 工厂配置查看器，以从第 3 步构造 EditPart。然后，将图模型对象传递给查看器。

												
														public class MyEditor extends GraphicalEditor {
    public MyEditor() {
        setEditDomain(new DefaultEditDomain(this));
    }

    protected void configureGraphicalViewer() {
        super.configureGraphicalViewer(); //Sets the viewer's background to System "white"
        getGraphicalViewer().setEditPartFactory(new MyGraphicalEditpartFactory());
    }

    protected void initializeGraphicalViewer() {
        getGraphicalViewer().setContents(MagicHelper.constructSampleDiagram());
    }
    public void doSave(IProgressMonitor monitor) {
        ...
    }
    public void doSaveAs() {
        ...
    }
    public void gotoMarker(IMarker marker) {
        ...
    }
    public boolean isDirty() {
        ...
    }
    public boolean isSaveAsAllowed() {
        ...
    }
}

												
										

回页首

接下来的步骤

我们已经经历了从仅拥有一个模型到在图形编辑器中显示该模型的全过程。但是我们只打下了基础。我们简要提及了编辑策略。通过阅读与 GEF SDK 一起提供的开发人员文档，可以获得有关编辑策略的更多信息。还可从 GEF 的主页（请参阅文章结尾的 参考资料）获得一个示例，该示例演示了如何使用各种编辑策略类型。

GEF 还提供了一个调色板。该调色板显示了一组工具，用于在图中创建对象。用户可以激活这些工具，或者使用本机拖放直接从该调色板拖动项。它还支持让用户定制内容。

在 GEF 中还可以使用几个 JFace 操作。应用程序可以在菜单、工具栏或上下文菜单中使用诸如撤销、对齐和删除之类的操作。

最后，您的应用程序应当支持大纲（outline）视图和特性（properties）视图。大纲视图用于导航和有限的编辑用途。GEF 的 TreeViewer 和／或概述（overview）窗口可以在这里使用。特性表（property sheet）允许用户查看和编辑任何当前选定项的详细特性。

为了显示所选择的项并允许用户进行更改，您必须将编辑策略添加到 EditPart。请参阅 GEF 主页上的示例，并参阅与 GEF SDK 一起提供的开发人员文档。

有关 GEF 和 Eclipse 工作台提供的其它功能的详细信息不在本文的讨论范畴之内，但是您可能有兴趣对它们稍做了解：

• 调色板。该工具的调色板是用于在图中创建新对象的 实际方法。GEF 包含了一个功能丰富的调色板，它支持拖放、多绘图程序和布局设置，如果应用程序希望，它甚至可支持让用户定制内容。
• 操作栏。编辑器（Editor）和视图（View）可以为工具栏、菜单和上下文菜单提供操作（Action）。GEF 提供了几个可重用的操作实现，但是将它们显示在什么地方取决于应用程序。
• 特性表。特性表可用于显示所选项特性的详细信息。GEF 允许您在 EditPart 上或在模型中添加特性表支持。
• 大纲。大纲视图通常用于显示图的结构化表示，但是一般来说，它可用于任何工作。GEF 的 TreeViewer 通常在大纲视图中使用。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请在 GEF 主页上下载插件并查找有关 GEF 的其它信息。
  
  
  
  
• GEF 新闻组 是查找答案和进行提问的极佳场所。
  
  
  
  
• Eclipse 项目 主管着 Eclipse 工作台、GEF 和其它开放源码技术。
  
  
  
  
• 请在 developerWorks上浏览 针对开发人员的其它 Eclipse 文章。
  
  
  

回页首

关于作者

		Randy Hudson 是北卡罗来纳州 Research Triangle Park 的 IBM 软件工程师。作为图形编辑框架（Graphical Editing Framework，GEF）的技术领导，他帮助将这个曾经是内部的项目转变成了开放源码技术。他目前的工作侧重于可用性、图形编辑、图形布局和边缘路由（edge routing）。可以通过 buchu at nc.rr.com与 Randy 联系。

• JVMDI 定义了虚拟机需要实现的本地接口
• JDWP 定义了JVM与调试客户端之间的通讯协议
  
  调试客户端和JVM 既可以在同一台机器上，也可以远程调试。JDK 会包含一个默认的实现 jdwp.dll，JVM 允许灵活的使用其他协议代替 JDWP。SUN JDK 有两种方式传输通讯协议：Socket 和共享内存(后者仅仅针对 Windows)，一般我们都采用 Socket 方式。
  
  你可以用下面的参数，以调试模式启动JVM
  
  

  -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Xrunjdwp JVM 加载 jdwp.dll transport=dt_socket 使用 Socket 传输 address 表示调试端口号 server=y 表示 JVM 作为服务器，建立 Socket suspend=n 表示启动过程中，JVM 不会挂起去等待调试客户端连接

  
  
• JDI 则是一组JAVA接口
  
  如果是一个 JAVA 的调试客户端，只要实现 JDI 接口，利用JDWP协议，与虚拟机通讯，就可以调用JVMDI了。
  

 
                          Components                        Debugger Interface 
              
                /    |-----------------------| 
               /     |     VM       | 
 debuggee ----(      |-----------------------|  <------- JVMDI - Java VM Debug Interface 
               \     |   back-end     | 
                \    |-----------------------| 
                /           | 
  comm channel -(           |  <--------------- JDWP - Java Debug Wire Protocol 
                \           | 
                     |---------------------| 
                     | front-end      | 
                     |---------------------|  <------- JDI - Java Debug Interface 
                     |      UI      | 
                     |---------------------| 
             

com.sun.jdi  
com.sun.jdi.connect  
com.sun.jdi.event  
com.sun.jdi.request 

• com.sun.jdi
  
  主要是JVM(VirtualMachine) 线程(ThreadReference) 调用栈(StackFrame) 以及类型、实例的描述。利用这组接口，调试客户端可以用类似类反射的方式，得到所有类型的定义，动态调用 Class 的方法。
• com.sun.jdi.event
  
  封装了JVM 产生的事件， JVM 正是将这些事件通知给调试客户端的。例如 BreakpointEvent 就是 JVM 执行到断点的时候，发出的事件；ClassPrepareEvent就是 Class 被加载时发出的事件。
  
  
• com.sun.jdi.request
  
  封装了调试客户端可以向 JVM发起的请求。例如 BreakpointRequest 向 JVM 发起一个添加断点的请求；ClassPrepareRequest 向 JVM 注册一个类加载请求，JVM 在加载指定 Class 的时候，就会发出一个 ClassPrepareEvent 事件。

 
          1    <HTML>     
          2    <HEAD>     
          3    <TITLE>Hello Example</TITLE>     
          4    </HEAD>     
          5    <BODY>     
          6    <%@ include file="greeting.jsp" %>     
          7    </BODY>     
          8    </HTML>   
          

Hello_jsp.java: 
1      package org.apache.jsp; 
2 
3      import javax.servlet.*; 
4      import javax.servlet.http.*; 
5      import javax.servlet.jsp.*; 
6       
7      public final class Hello_jsp extends org.apache.jasper.runtime.HttpJspBase 
8          implements org.apache.jasper.runtime.JspSourceDependent { 
9       
10        private static java.util.Vector _jspx_dependants; 
11       
12        static { 
13          _jspx_dependants = new java.util.Vector(1); 
14          _jspx_dependants.add("/greeting.jsp"); 
15        } 
16       
17        public java.util.List getDependants() { 
18          return _jspx_dependants; 
19        } 
20       
21  public void _jspService(HttpServletRequest request, HttpServletResponse response) 
22              throws java.io.IOException, ServletException { 
23       
24          JspFactory _jspxFactory = null; 
25          PageContext pageContext = null; 
26          HttpSession session = null; 
27          ServletContext application = null; 
28          ServletConfig config = null; 
29          JspWriter out = null; 
30          Object page = this; 
31          JspWriter _jspx_out = null; 
32       
33       
34          try { 
35            _jspxFactory = JspFactory.getDefaultFactory(); 
36            response.setContentType("text/html"); 
37            pageContext = _jspxFactory.getPageContext(this, request, response, 
38               null, true, 8192, true); 
39            application = pageContext.getServletContext(); 
40            config = pageContext.getServletConfig(); 
41            session = pageContext.getSession(); 
42            out = pageContext.getOut(); 
43            _jspx_out = out; 
44       
45            out.write("<HTML>    \r\n"); 
46            out.write("<HEAD>    \r\n"); 
47            out.write("<TITLE>Hello Example"); 
48            out.write("</TITLE>    \r\n"); 
49            out.write("</HEAD>    \r\n"); 
50            out.write("<BODY>    \r\n"); 
51            out.write("Hello There!"); 
52            out.write("<P>    \r\nGoodbye on "); 
53            out.write(String.valueOf( new java.util.Date() )); 
54            out.write("  \r\n"); 
55            out.write("    \r\n"); 
56            out.write("</BODY>    \r\n"); 
57            out.write("</HTML>  \r\n"); 
58          } catch (Throwable t) { 
59            if (!(t instanceof javax.servlet.jsp.SkipPageException)){ 
60              out = _jspx_out; 
61              if (out != null && out.getBufferSize() != 0) 
62                out.clearBuffer(); 
63              if (pageContext != null) pageContext.handlePageException(t); 
64            } 
65          } finally { 
66     if (_jspxFactory != null) _jspxFactory.releasePageContext ( pageContext); 
67          } 
68        } 
69      }

SourceDebugExtension_attribute { 
  u2 attribute_name_index; 
  u4 attribute_length; 
  u1 debug_extension[attribute_length]; 
} 

 
public static void main(String[] args) throws Exception{ 
   String[]files = { 
　　　"E:\\Tomcat5_0_5\\work\\Catalina\\localhost\\_\\org\\apache\\jsp\\Hello_jsp.class", 
   }; 
                 
　for(int k = 0; k < files.length; k++){ 
  　 String file = files[k]; 
  　 System.out.println("Class : " + file); 
  　 ClassFile classFile = new ClassFile(new DataInputStream(new FileInputStream(file))); 
  　         
  　 AttributeInfo attributeInfo = classFile.getAttribute("SourceDebugExtension"); 
  　 System.out.println("attribute name :" + attributeInfo.getName() + "]\n\n"); 
  　 byte[]bytes = attributeInfo.get(); 
  　 String str = new String(bytes); 
  　 System.out.println(str);    
   } 
} 

SMAP 
E:\Tomcat5_0_5\work\Catalina\localhost\_\org\apache\jsp\Hello_jsp.java 
JSP 
*S JSP 
*F 
+ 0 Hello.jsp 
/Hello.jsp 
+ 1 greeting.jsp 
/greeting.jsp 
*L 
1:45 
2:46 
3:47 
3:48 
4:49 
5:50 
1#1:51 
1:52 
2:53 
7#0:56 
8:57 
*E

 
1:45  2:46  3:47  3:48  4:49  5:50(没有源文件代号，默认为Hello.jsp) 
　　　　　　　　　　　　　　　　　　　开始行号 　　结束行号 
Hello.jsp:    1 ->  Hello_jsp.java:    45 
              2 ->                     46 
              3 ->                     47           48 
              4 ->                     49 
              5 ->                     50 

1#1:51  1:52  2:53(1#1表示 greeting.jsp 的第1行) 
greeting.jsp:    1 ->  Hello_jsp.java:       51           52 
                 2 ->                     53  
         
7#0:56  8:57(7#0表示 Hello.jsp 的第7行) 
Hello.jsp:     7 ->  Hello_jsp.java:       56 
               8 ->                     57 

public class ManageBreakpointRulerActionDelegate extends AbstractRulerActionDelegate{ 
 protected IAction createAction(ITextEditor editor, IVerticalRulerInfo rulerInfo) { 
  return new ManageBreakpointRulerAction(rulerInfo, editor); 
 } 
} 

<extension  point="org.eclipse.ui.editorActions"> 
　<editorContribution 
      targetID="com.jiaoly.editors.JSPEditor" 
      id="com.jiaoly.debug.ManageBreakpointRulerActionDelegate"> 
　　　<action 
         label="添加/删除断点" 
         class="com.jiaoly.debug.ManageBreakpointRulerActionDelegate" 
         actionID="RulerDoubleClick" 
         id="com.jiaoly.debug.ManageBreakpointRulerActionDelegate"> 
　　　</action> 
　</editorContribution> 
</extension> 
       

<extension point="org.eclipse.ui.popupMenus"> 
 <viewerContribution 
     targetID="#TextRulerContext" 
     id="com.jiaoly.debug.ManageBreakpointRulerActionDelegate"> 
     <action 
       label="添加/删除断点" 
       class="com.jiaoly.debug.ManageBreakpointRulerActionDelegate" 
       menubarPath="addition" 
       id="com.jiaoly.debug.ManageBreakpointRulerActionDelegate"> 
    </action> 
 </viewerContribution> 
</extension> 

public class ManageBreakpointRulerAction extends Action implements IUpdate{ 
      
     private IVerticalRulerInfo rulerInfo; 
     private ITextEditor textEditor; 
     
     private String BPmarkerType ;     //当点Marker的类型 
     private List allMarkers;       //当前鼠标点击行所有的Marker 
     private String addBP;   //Action 的显示名称 
     
public ManageBreakpointRulerAction(IVerticalRulerInfo ruler, ITextEditor editor){ 
     this.rulerInfo = ruler; 
     this.textEditor = editor; 
     BPmarkerType = IBreakpoint.BREAKPOINT_MARKER; 
     addBP = "添加/删除断点"; //$NON-NLS-1$ 
     setText(this.addBP); 
} 
     
public void update() { 
  this.allMarkers = this.fetchBPMarkerList();  
} 
     
public void run(){ 
 if(this.allMarkers.isEmpty()) 
   this.addMarker(); 
 else 
   this.removeMarkers(this.allMarkers); 
} 
} 
  

 
ManageBreakpointRulerAction.update() line: 55 
ManageBreakpointRulerActionDelegate(AbstractRulerActionDelegate).update() line: 114 
ManageBreakpointRulerActionDelegate(AbstractRulerActionDelegate).mouseDown(MouseEvent) line: 139 

 
  protected void addMarker() { 
  IEditorInput editorInput= this.getTextEditor().getEditorInput(); 
   
  IDocument document= this.getDocument(); 
  //the line number of the last mouse button activity 
  int rulerLine= this.getRulerInfo().getLineOfLastMouseButtonActivity(); 

  try{ 
   int lineNum = rulerLine + 1; 
   if(lineNum > 0){ 
       //Returns a description of the specified line 
    IRegion iregion = document.getLineInformation(lineNum - 1); 
    int charStart = iregion.getOffset(); 
    int charEnd = (charStart + iregion.getLength()) - 1; 
    JSPDebugUtility.createJspLineBreakpoint(this.getResource(),  
             lineNum, charStart, charEnd); 
   } 
  }catch(CoreException coreexception){ 
   coreexception.printStackTrace(); 
  } 
  catch(BadLocationException badlocationexception){ 
   badlocationexception.printStackTrace(); 
  }   
 } 
 

 
        public class JSPBreakpoint extends JavaStratumLineBreakpoint { 
        public JSPBreakpoint(IResource resource, String stratum, String sourceName, 
                String sourcePath, String classNamePattern, int lineNumber, 
                int charStart, int charEnd, int hitCount, boolean register, 
                Map attributes) throws DebugException { 
            super(resource, stratum, sourceName, sourcePath, classNamePattern, 
                    lineNumber, charStart, charEnd, hitCount, register, attributes); 
        } 
    } 

 
    IWorkspaceRunnable wr= new IWorkspaceRunnable() { 
   public void run(IProgressMonitor monitor) throws CoreException { 
    // create the marker 
    setMarker(resource.createMarker(markerType));     
    // modify pattern 
    String pattern = classNamePattern; 
    if (pattern != null && pattern.length() == 0) { 
     pattern = null; 
    } 
    // add attributes 
    addLineBreakpointAttributes(attributes, getModelIdentifier(), true,  
          lineNumber, charStart, charEnd); 
    addStratumPatternAndHitCount(attributes, stratum, sourceName,  
sourcePath, pattern, hitCount); 
    // set attributes 
    ensureMarker().setAttributes(attributes); 
     
    register(register); 
   } 
  }; 
  run(null, wr); 
     
    protected void register(boolean register) throws CoreException { 
  if (register) { 
   DebugPlugin.getDefault().getBreakpointManager().addBreakpoint(this); 
  } else { 
   setRegistered(false); 
  } 
 } 
  

breakpointManager  = DebugPlugin.getDefault().getBreakpointManager(); 
IBreakpoint breakpoint = breakpointManager.getBreakpoint(IMarker); 
breakpointManager.removeBreakpoint(breakpoint, true); 
        

 
  public void addToTarget(JDIDebugTarget target) throws CoreException { 
  IMarker marker = this.getMarker(); 
     IResource resource = marker.getResource(); 
     String targetString = target.getLaunch().getLaunchConfiguration().getName(); 
  IJSPNameUtil util = JSPDebugUtility.getJSPNameUtil(targetString); 
      
  // pre-notification 
  fireAdding(target); 
     
  String referenceTypeName; 
  try { 
   referenceTypeName = getPattern(); 
   //如果没有设置 Pattern, 根据 Server 的类型, 产生新的 Pattern  
   if(referenceTypeName == null ||  
      "".equals(referenceTypeName.trim()) || 
      "*".equals(referenceTypeName.trim())){ 
       referenceTypeName = util.referenceTypeName(resource); 
   } 
    
  } catch (CoreException e) { 
   JDIDebugPlugin.log(e); 
   return; 
  } 
   
  this.ensureMarker().setAttribute(TYPE_NAME, referenceTypeName); 
  String sourcePath = util.sourcePath(resource); 
  this.ensureMarker().setAttribute(JSPBreakpoint.SOURCE_PATH, sourcePath); 
   
  String classPrepareTypeName= referenceTypeName; 
   
  //如果这时 class 还没有被加载, 注册一个 ClassPrepareRequest 请求 
  // 
  //当 class 加载的时候, 首先会触发 JavaBreakpoint 的 handleClassPrepareEvent 方法 
  //调用 createRequest(target, event.referenceType()) --> newRequest() --> 
  //    createLineBreakpointRequest() 创建 enable或disable 断点的请求 
  // 
  //  设置 enable/disable 动作在 configureRequest() --> updateEnabledState(request) 方法中 
  //  根据 getMarker().getAttribute(ENABLED, false) 确定断点是否有效 
   
  registerRequest(target.createClassPrepareRequest(classPrepareTypeName), target); 
   
  // create breakpoint requests for each class currently loaded 
  VirtualMachine vm = target.getVM(); 
  if (vm == null) { 
   target.requestFailed("Unable_to_add_breakpoint_-_VM_disconnected._1"),  
   null);   } 
  List classes = null; 
  try { 
   classes= vm.allClasses(); 
  } catch (RuntimeException e) { 

   target.targetRequestFailed("JavaPatternBreakpoint.0"), e);  
  } 
  if (classes != null) { 
   Iterator iter = classes.iterator(); 
   while (iter.hasNext()) { 
    ReferenceType type= (ReferenceType)iter.next(); 
    if (installableReferenceType(type, target)) { 
     createRequest(target, type); 
    } 
   } 
  } 
 }     

 
    D:\j2sdk1.4.2\bin\java   
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8888,server=y,
     suspend=n -Djava.endorsed.dirs="..\common\endorsed" 
-classpath "D:\j2sdk1.4.2\lib\tools.jar;..\bin\bootstrap.jar"  
-Dcatalina.base=".."  
-Dcatalina.home=".."  
-Djava.io.tmpdir="..\temp"  
org.apache.catalina.startup.Bootstrap  start 

<jspAttributes xmi:id="JSPAttribute_0" name="keepgenerated" value="true"/> 
<jspAttributes xmi:id="JSPAttribute_1" name="createDebugClassfiles" value="true"/> 
<jspAttributes xmi:id="JSPAttribute_2" name="debugEnabled" value="true"/>