http://www.ftponline.com/weblogicpro/2005_01/magazine/columns/troubleshootingdiary/default_pf.aspx

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Oracle with语句示例

WITH a AS (SELECT * FROM bd_member WHERE ROWNUM<10),
b AS (SELECT * FROM tp_trade_card)
select A.MEMBER_NAME,
B.CARD_NO
from A,
B
where A.BD_MEMBER_ID = B.BD_MEMBER_ID

Google Search: Oracle +with 视图就可以得到结果...

Oracle WITH clause Oracle Tips by Burleson Consulting

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

www.mamashuojiusuannizhucedeyumingzaichanggoogledounengsousuochulai.cn

中文拼音："妈妈说就算你注册的域名再长GOOGLE都能搜索出来"

www.mamashuojiusuannizhucedeyumingzaichangbaidudounengsousuochulai.cn
中文拼音："妈妈说就算你注册的域名再长百度都能搜索出来"

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

原文链接：http://gceclub.sun.com.cn/yuanchuang/week-9/classloader.html

Java类装载体系中的隔离性

作者：盛戈歆

作者简介

盛戈歆，软件工程师，你可以通过shenggexin@topwaver.com与他联系。

正文

Java中类的查找与装载出现的问题总是会时不时出现在Java程序员面前，这并不是什么丢脸的事情，相信没有一个Java程序员没遇到过ClassNotException,因此不要为被人瞅见自己也犯这样的错误而觉得不自然，但是在如果出现了ClassNotFoundException后异常后一脸的茫然，那我想你该了解一下java的类装载的体制了，同时为了进行下面的关于类装载器之间的隔离性的讨论，我们先简单介绍一下类装载的体系结构。

1. Java类装载体系结构

装载类的过程非常简单：查找类所在位置，并将找到的Java类的字节码装入内存，生成对应的Class对象。Java的类装载器专门用来实现这样的过程，JVM并不止有一个类装载器，事实上，如果你愿意的话，你可以让JVM拥有无数个类装载器，当然这除了测试JVM外，我想不出还有其他的用途。你应该已经发现到了这样一个问题，类装载器自身也是一个类，它也需要被装载到内存中来，那么这些类装载器由谁来装载呢，总得有个根吧？没错，确实存在这样的根，它就是神龙见首不见尾的Bootstrap ClassLoader. 为什么说它神龙见首不见尾呢，因为你根本无法在Java代码中抓住哪怕是它的一点点的尾巴，尽管你能时时刻刻体会到它的存在，因为java的运行环境所需要的所有类库，都由它来装载，而它本身是C++写的程序，可以独立运行,可以说是JVM的运行起点,伟大吧。在Bootstrap完成它的任务后，会生成一个AppClassLoader(实际上之前系统还会使用扩展类装载器ExtClassLoader，它用于装载Java运行环境扩展包中的类),这个类装载器才是我们经常使用的，可以调用ClassLoader.getSystemClassLoader() 来获得，我们假定程序中没有使用类装载器相关操作设定或者自定义新的类装载器，那么我们编写的所有java类通通会由它来装载，值得尊敬吧。AppClassLoader查找类的区域就是耳熟能详的Classpath，也是初学者必须跨过的门槛，有没有灵光一闪的感觉，我们按照它的类查找范围给它取名为类路径类装载器。还是先前假定的情况，当Java中出现新的类，AppClassLoader首先在类传递给它的父类类装载器，也就是Extion ClassLoader，询问它是否能够装载该类，如果能，那AppClassLoader就不干这活了，同样Extion ClassLoader在装载时，也会先问问它的父类装载器。我们可以看出类装载器实际上是一个树状的结构图，每个类装载器有自己的父亲，类装载器在装载类时，总是先让自己的父类装载器装载(多么尊敬长辈),如果父类装载器无法装载该类时，自己就会动手装载，如果它也装载不了，那么对不起，它会大喊一声：Exception，class not found。有必要提一句，当由直接使用类路径装载器装载类失败抛出的是NoClassDefFoundException异常。如果使用自定义的类装载器loadClass方法或者ClassLoader的findSystemClass方法装载类，如果你不去刻意改变，那么抛出的是ClassNotFoundException。

我们简短总结一下上面的讨论：

1.JVM类装载器的体系结构可以看作是树状结构。

2.父类装载器优先装载。在父类装载器装载失败的情况下再装载，如果都装载失败则抛出ClassNotFoundException或者NoClassDefFoundError异常。

那么我们的类在什么情况下被装载的呢？

在java2中，JVM是如何装载类的呢，可以分为两种类型，一种是隐式的类装载，一种式显式的类装载。

隐式的类装载是编码中最常用得方式：

A b = new A();

如果程序运行到这段代码时还没有A类，那么JVM会请求装载当前类的类装器来装载类。问题来了，我把代码弄得复杂一点点，但依旧没有任何难度，请思考JVM得装载次序：

package test;
Public class A{
    public void static main(String args[]){
        B b ＝ new B();
    }
}

class B{C c;}

class C{}

揭晓答案，类装载的次序为A->B，而类C根本不会被JVM理会,先不要惊讶，仔细想想，这不正是我们最需要得到的结果。我们仔细了解一下JVM装载顺序。当使用Java A命令运行A类时，JVM会首先要求类路径类装载器(AppClassLoader)装载A类，但是这时只装载A，不会装载A中出现的其他类(B类)，接着它会调用A中的main函数，直到运行语句b ＝ new B()时，JVM发现必须装载B类程序才能继续运行，于是类路径类装载器会去装载B类，虽然我们可以看到B中有有C类的声明，但是并不是实际的执行语句，所以并不去装载C类，也就是说JVM按照运行时的有效执行语句，来决定是否需要装载新类，从而装载尽可能少的类，这一点和编译类是不相同的。

2.2 显式的类装载

使用显示的类装载方法很多，我们都装载类test.A为例。

使用Class类的forName方法。它可以指定装载器，也可以使用装载当前类的装载器。例如：

Class.forName("test.A");
它的效果和
Class.forName("test.A",true,this.getClass().getClassLoader());
是一样的。

使用类路径类装载器装载.

ClassLoader.getSystemClassLoader().loadClass("test.A");

使用当前进程上下文的使用的类装载器进行装载，这种装载类的方法常常被有着复杂类装载体系结构的系统所使用。

Thread.currentThread().getContextClassLoader().loadClass("test.A")

使用自定义的类装载器装载类

public class MyClassLoader extends URLClassLoader{
public MyClassLoader() {
        super(new URL[0]);
    }
}
MyClassLoader myClassLoader = new MyClassLoader();
myClassLoader.loadClass("test.A");

MyClassLoader继承了URLClassLoader类，这是JDK核心包中的类装载器，在没有指定父类装载器的情况下，类路径类装载器就是它的父类装载器，MyClassLoader并没有增加类的查找范围，因此它和类路径装载器有相同的效果。

我们已经知道Java的类装载器体系结构为树状，多个类装载器可以指定同一个类装载器作为自己的父类，每个子类装载器就是树状结构的一个分支，当然它们又可以个有子类装载器类装载器，类装载器也可以没有父类装载器，这时Bootstrap类装载器将作为它的隐含父类，实际上Bootstrap类装载器是所有类装载器的祖先，也是树状结构的根。这种树状体系结构，以及父类装载器优先的机制，为我们编写自定义的类装载器提供了便利，同时可以让程序按照我们希望的方式进行类的装载。例如某个程序的类装载器体系结构图如下：

图2：某个程序的类装载器的结构

解释一下上面的图，ClassLoaderA为自定义的类装载器，它的父类装载器为类路径装载器，它有两个子类装载器ClassLoaderAA和ClassLaderAB，ClassLoaderB为程序使用的另外一个类装载器，它没有父类装载器，但有一个子类装载器ClassLoaderBB。你可能会说，见鬼，我的程序怎么会使用这么复杂的类装载器结构。为了进行下面的讨论，暂且委屈一下。

3. 奇怪的隔离性

我们不难发现，图2中的类装载器AA和AB， AB和BB，AA和B等等位于不同分支下，他们之间没有父子关系，我不知道如何定义这种关系，姑且称他们位于不同分支下。两个位于不同分支的类装载器具有隔离性，这种隔离性使得在分别使用它们装载同一个类，也会在内存中出现两个Class类的实例。因为被具有隔离性的类装载器装载的类不会共享内存空间，使得使用一个类装载器不可能完成的任务变得可以轻而易举，例如类的静态变量可能同时拥有多个值（虽然好像作用不大），因为就算是被装载类的同一静态变量，它们也将被保存不同的内存空间，又例如程序需要使用某些包，但又不希望被程序另外一些包所使用，很简单，编写自定义的类装载器。类装载器的这种隔离性在许多大型的软件应用和服务程序得到了很好的应用。下面是同一个类静态变量为不同值的例子。

package test;
public class A {
  public static void main( String[] args ) {
    try {
      //定义两个类装载器
      MyClassLoader aa= new MyClassLoader();
      MyClassLoader bb = new MyClassLoader();

      //用类装载器aa装载testb.B类
      Class clazz=aa.loadClass("testb. B");
      Constructor constructor= 
        clazz.getConstructor(new Class[]{Integer.class});
      Object object = 
	    constructor.newInstance(new Object[]{new Integer(1)});
      Method method = 
	    clazz.getDeclaredMethod("printB",new Class[0]);

      //用类装载器bb装载testb.B类
      Class clazz2=bb.loadClass("testb. B");
      Constructor constructor2 = 
        clazz2.getConstructor(new Class[]{Integer.class});
      Object object2 = 
	    constructor2.newInstance(new Object[]{new Integer(2)});
      Method method2 = 
	    clazz2.getDeclaredMethod("printB",new Class[0]);

      //显示test.B中的静态变量的值 
      method.invoke( object,new Object[0]);
      method2.invoke( object2,new Object[0]);
    } catch ( Exception e ) {
      e.printStackTrace();
    }
  }
}

//Class B 必须位于MyClassLoader的查找范围内，
//而不应该在MyClassLoader的父类装载器的查找范围内。
package testb;
public class B {
    static int b ;

    public B(Integer testb) {
        b = testb.intValue();
    }

    public void printB() {
        System.out.print("my static field b is ", b);
    }
}

public class MyClassLoader extends URLClassLoader{
  private static File file = new File("c:\\classes ");
  //该路径存放着class B，但是没有class A

  public MyClassLoader() {
    super(getUrl());
  }

  public static URL[] getUrl() {
    try {
      return new URL[]{file.toURL()};
    } catch ( MalformedURLException e ) {
      return new URL[0];
    }
  }
}

程序的运行结果为：

my static field b is 1
my static field b is 2

程序的结果非常有意思，从编程者的角度，我们甚至可以把不在同一个分支的类装载器看作不同的java虚拟机，因为它们彼此觉察不到对方的存在。程序在使用具有分支的类装载的体系结构时要非常小心，弄清楚每个类装载器的类查找范围，尽量避免父类装载器和子类装载器的类查找范围中有相同类名的类（包括包名和类名），下面这个例子就是用来说明这种情况可能带来的问题。

假设有相同名字却不同版本的接口 A，

版本 1：
package test;
Intefer Same{ public String getVersion(); }
版本 2：
Package test;
Intefer Same{ public String getName(); }

接口A两个版本的实现：

版本1的实现
package test;
public class Same1Impl implements Same {
public String getVersion(){ return "A version 1";}
}
版本2的实现
public class Same 2Impl implements Same {
public String getName(){ return "A version 2";}
}

我们依然使用图2的类装载器结构，首先将版本1的Same和Same的实现类Same1Impl打成包same1.jar，将版本2的Same和Same的实现类Same1Impl打成包same2.jar。现在，做这样的事情，把same1.jar放入类装载器ClassLoaderA的类查找范围中，把same2.jar放入类装器ClassLoaderAB的类查找范围中。当你兴冲冲的运行下面这个看似正确的程序。

实际上这个错误的是由父类载器优先装载的机制造成，当类装载器ClassLoaderAB在装载Same2Impl类时发现必须装载接口test.Same，于是按规定请求父类装载器装载，父类装载器发现了版本1的test.Same接口并兴冲冲的装载，但是却想不到Same2Impl所希望的是版本2 的test.Same，后面的事情可想而知了，异常被抛出。

我们很难责怪Java中暂时并没有提供区分版本的机制，如果使用了比较复杂的类装载器体系结构，在出现了某个包或者类的多个版本时，应特别注意。

掌握和灵活运用Java的类装载器的体系结构，对程序的系统设计，程序的实现，已经程序的调试，都有相当大的帮助。希望以上的内容能够对您有所帮助。

 

Ext1

Class.forName(String clz); 使用调用这个语句的对象所使用的ClassLoader作为ClassLoader(1)。(请查看代码) Thread.currentThread().getContextClassLoader()) 返回当前线程使用的ClassLoader(2)。 如果ClassLoader(1)“等于”ClassLoader(2)，那么这里的使用Class.forName(String clz)和ClassLoader(2).loadClass(String clz)就是等价的。 如果ClassLoader(1)“不等于”ClassLoader(2)，那么就是不等价的。 在框架代码中，实际情况是ClassLoader(1)往往“不等于”ClassLoader(2)： 即调用Class.forName(String clz)的语句所在的类的装载器不一定就是当前线程使用的类装载器。 因为：一个类装载完了在运行了，该类的所属的类装载器就确定了(不变)，而在程序运行之中，线程的类装载器都随时可以通过hread.currentThread().setContextClassLoader(loader)进行改变(变)。

Class.forName有两个签名Class.forName(String)和Class.forName(String, boolean, ClassLoader)，最终都是调用内部native方法forName0，第一个签名实现是return forName0(className, true, ClassLoader.getCallerClassLoader())，第二个稍微复杂一些，但是大概认为是在当指定loader==null的时候使用ClassLoader.getCallerClassLoader(). 再看ClassLoader.getCallerClassLoader()怎么实现，很简单通过一个native方法得到caller class然后getClassLoader() 现在结论很简单了，当caller class不是由current thread的context ClassLoader load的时候，两者的结果会不一致

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

 moneyice的专栏：

http://blog.csdn.net/moneyice/

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

http://www-128.ibm.com/developerworks/cn/opensource/os-ecl-osgibdev/index.html

开放服务网关协议 (Open Services Gateway Initiative)，简称 OSGi,为网络服务定义了一个标准的、面向服务的计算环境，为用户提供了开放的、面向服务组件的、易于部署的编程模型，这个编程模型允许用户将定义好的接口规范绑定到 OSGi 运行环境中的特定Service，在构件 SOA 面向服务为中心的企业应用的过程中，OSGi 技术正发挥越来越重要的作用。在本文中，将介绍 OSGi 的概念和体系结构，并且利用 Eclipse 3.2 开发一个基于 OSGi 规范的服务应用 Bundle。通过学习本文，读者可以了解到如何开发和部署基于 OSGi 规范的 Bundle 应用。

OSGi 规范简介

OSGi 联盟建立于 1999 年，是一个非赢利机构，旨在建立一个开放的服务规范。OSGi 规范为网络服务定义了一个标准的、面向组件的计算环境，它最初的目的就是为各种嵌入式设备提供通用的软件运行平台，屏蔽设备操作系统与硬件区别的中间件平台，通过这个平台，可以对不同软件商提供的应用(OSGi 中称为 Bundle)进行组件的生命周期管理的能力，如应用组件可以从运行中被安装、升级或者移除而不需要中断设备的操作，应用组件可以动态的发现和使用其他库或者应用程序。由于 OSGi 技术具有服务组件模块化、动态加载应用等优点，正被越来越多的领域关注，如嵌入设备制造业、汽车制造业、企业应用等。目前，OSGi 联盟发布的最新的 OSGi 服务规范为 4.0，读者可以查阅参考资料了解详细信息。

回页首

OSGi 体系结构

OSGi 的体系架构是基于插件式的软件结构，包括一个 OSGi 框架和一系列插件，在 OSGi中，插件称为 Bundle，其中，OSGi 框架规范是 OSGi 规范的核心部分，它提供了一个通用的、安全可管理的 Java 框架，通过这个框架，可以支持 Bundle 服务应用的部署和扩展。Bundle 之间可以通过 Import Package 和 Require-Bundle 来共享 Java 类，在 OSGi 服务平台中，用户通过开发 Bundle 来提供需要的功能，这些 Bundle 可以动态加载和卸载，或者根据需要远程下载和升级。OSGi 体系结构图如图 1 所示：

其中：

Execution Environment：

Bundle 应用所倚赖运行的 Java 执行环境，如 J2SE-1.4、CDC-1.0 等都是可用的执行环境。

Modules：

模块层定义了 Bundle 应用的加载策略。OSGi 框架是一个健壮并且严格定义的类加载模型。在大多数 Java 应用中，通常只有一个单独的 ClassPath，它包含了所有的 Java 类文件和资源文件，OSGi基于Java技术，对于每个实现了 BundleActivator 接口的 Bundle 应用，为它生成一个单独的 ClassLoader，使得 Bundle 应用的组织更加模块化。

Life Cycle：

生命周期层可以动态地对 Bundle 进行安装、启动、停止、升级和卸载等操作。该层基于模块层，提供了一组 API 来控制 Bundle 应用的运行时操作。

Service Registry 和 Services：

OSGi 服务层定义了一个集成在生命周期层中的动态协作模型，是一个发布、动态寻找、绑定的服务模型。一个服务通常是一个 Java 对象实现了特定的服务接口，并且通过服务注册，被绑定到 OSGi 的运行环境中。Bundle 应用可以注册发布服务，动态绑定服务，并且在服务注册状态改变时，可以接受到事件消息等。

Security：

OSGi 的安全管理是基于 Java2 安全体系的，贯穿在 OSGi 平台的所有层中，它能够对部署在 OSGi 运行环境中的 Bundle 应用进行详细的管理控制。

回页首

Bundle 生命周期的状态

在一个动态扩展的 OSGi 环境中，OSGi 框架管理 Bundle 的安装和更新，同时也管理 Bundle 和服务之间的依赖关系。一个 Bundle 可能处于以下六个状态，如图 2 所示：

INSTALLED：安装完成，本地资源成功加载。

RESOLVED：依赖关系满足，这个状态意味该Bundle要么已经准备好运行，要么是被停止了。

STARTING：Bundle正在被启动，BundleActivator的start()方法已经被调用但是还没有返回。

STOPPING：Bundle正在被停止，BundleActivator的stop()方法已经被调用但是还没有返回。

ACTIVE：Bundle 被成功启动并且在运行。

UNINSTALLED：bundle被卸载并且无法进入其他状态。

Bundle接口定义了getState()方法来返回Bundle的状态。

回页首

OSGi 标准服务

在 OSGi 平台之上，OSGi 联盟定义了很多服务。服务是由一个 Java Interface 来定义的，Bundle 可以实现这个接口并且把服务注册到服务注册表中去，用户可以从注册表中找到需要的服务来使用，并且可以响应特定服务的状态改变，如服务注册和服务取消。下面简单介绍一下 OSGi Release 4 的一些主要服务。OSGi 框架提供了权限管理服务，包管理服务和最初加载系统服务。这些服务是 OSGi 框架的一部分并且管理着 OSGi 框架的运作。

Permission Admin Service：权限管理是指 Bundle 是否许可其他的 Bundle 的代码。当前的或者其他的 Bundle 的权限可以通过这个服务来操作，一旦被设定权限，马上就生效。 Package Admin Service：Bundle 之间可以共享包内的 Java 类和资源，bundle 的更新可能需要 OSGi 框架重新解析 Bundle 之间的依赖关系，这个服务提供了 OSGi 服务平台中包的共享状态信息。

Start Level Service：Start Level是指一些在特定Bundle起动之前必须运行或者初始化的一系列 bundle。Start Lever Service 可以设置当前OSGi服务框架初始的Start Level，并且可以指定和查询特定Bundle的Start Level。

回页首

使用 Eclipse 开发 Bundle 应用

Equinox 框架是 Eclipse 组织基于 OSGi Release 4 的一个实现框架，它实现了 OSGi 规范的核心框架和许多标准框架服务的实现。关于Equinox项目的详细信息，请查阅参考资料信息。在本文中，我们使用 Eclipse 3.2 平台开发两个基于 OSGi 的 Bundle 应用，其中第一个 Bundle 应用声明、实现并注册了一个姓名查询服务，用于判断所给姓名是否在已定义的查询列表中；第二个 Bundle 应用查询并引用第一个 Bundle 应用所注册的姓名查询服务，如果用户所给的姓名包含在查询列表中，将返回正确的信息，最后，将开发的 Bundle应用部署的 Equinox OSGi 框架中，用户可以在 OSGi 控制命令行中输入命令来查询关于框架和 Bundle 应用的具体信息。读者可以从参考资料中获得本文 Bundle 应用的源代码。

(1)创建 Plug-in Project，在 Eclipse 3.2 开发环境中，从菜单栏选择 File > New > Project... ，打开 New Project 向导，可以看到有Plug-in Project创建向导，创建一个Plug-in 项目。项目名为 example 的 Bundle 应用，该应用实现并注册了一个姓名查询服务，实现了 BundleActivator 接口。选择 Equinox 框架作为 Bundle 应用运行的 OSGi 服务平台。

(2)实现OSGi服务通常需要两个步骤，首先定义所提供服务的接口，然后实现这个服务接口。在本例中，我们创建一个姓名查询服务用来查询所给姓名是否有效。首先定义姓名查询接口NameService.java。下面是该接口的源代码：

package example.service;
/**
 * A simple service interface that defines a name service.
 * A name service simply verifies the existence of a Name.
**/
public interface NameService {
	/**
     * Check for the existence of a Name.
     * @param name the Name to be checked.
     * @return true if the Name is in the list,
     *         false otherwise.
    **/
	public boolean checkName(String name);
}

该服务接口很简单，只包含一个需要实现的方法。为了将服务接口和服务实现相分离，方便其他 Bundle 引用该服务，我们通常需要将该服务接口单独放在一个包内，本例中，存放NameService.java 接口的 Java 包为 example.service。接下来，需要实现 NameService 接口，并且注册该服务。在本例中，我们用内部类实现了该接口，下面是该 Bundle 应用的部分源代码。

	public void start(BundleContext context) throws Exception {
		Properties props = new Properties();
		props.put("ClassRoom", "ClassOne");
		context.registerService(NameService.class.getName(), new NameImpl(),
				props);
	}
private static class NameImpl implements NameService {
		// The set of names contained in the arrays.
		String[] m_name = { "Marry", "John", "David", "Rachel", "Ross" };
		/**
		 * Implements NameService.checkName(). Determines if the passed name is
		 * contained in the Array.
		 * 
		 * @param name
		 *            the name to be checked.
		 * @return true if the name is in the Array, false otherwise.
		 */
		public boolean checkName(String name) {
			// This is very inefficient
			for (int i = 0; i < m_name.length; i++) {
				if (m_name[i].equals(name)) {
					return true;
				}
			}
			return false;
		}
	} 
	

在start()方法中，利用BundleContext注册一个姓名查询服务，并且为该服务设置相关属性以便服务查询。在实现姓名查询服务时，我们简单定义了一个静态数组用于存放有效的姓名信息。

(3)定义Bundle描述文件MANIFEST.MF，Bundle应用example的MANIFEST.MF文件如下：

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Example Bundle
Bundle-SymbolicName: example
Bundle-Version: 1.0.0
Bundle-Activator: example.osgi.Activator
Bundle-Localization: plugin
Import-Package: org.osgi.framework;version="1.3.0"
Export-Package: example.service

其中，Bundle-Activator属性指明了实现BundleActivator接口的类，该类用来启动和停止Bundle应用。Export-Package属性指定了该Bundle输出的共享包，该属性可以使其他的Bundle应用引用我们所定义的服务接口。

(4)创建项目名为exampleClient的Bundle应用，该应用在OSGi平台上查寻并引用example Bundle应用已经注册的姓名查询服务，然后从标准输入读入用户所输入的姓名信息，判断所输入姓名是否有效。exampleClient应用的部分源代码如下，读者可从参考资料中获得完整源代码。

	public void start(BundleContext context) throws Exception {
		ServiceReference[] refs = context.getServiceReferences(
				NameService.class.getName(), "(ClassRoom=*)");
		if (refs != null) {
			try {
				System.out.println("Enter a blank line to exit.");
				BufferedReader in = new BufferedReader(new InputStreamReader(
						System.in));
				String name = "";
				// Loop endlessly.
				while (true) {
					// Ask the user to enter a name.
					System.out.print("Enter a Name: ");
					name = in.readLine();
					// If the user entered a blank line, then
					// exit the loop.
					if (name.length() == 0) {
						break;
					}
					// First, get a name service and then check
					// if the name is correct.
					NameService nameservice = (NameService) context
							.getService(refs[0]);
					if (nameservice.checkName(name)) {
						System.out.println("The Name is Correct.");
					} else {
						System.out.println("The Name is Incorrect.");
					}
					// Unget the name service.
					context.ungetService(refs[0]);
				}
			} catch (IOException ex) {
			}
		} else {
			System.out.println("Couldn't find any name service...");
		}
	}
	

回页首

Bundle的部署及运行

在Eclipse平台中，选择File-->Export...菜单，将开发的example和exampleClient两个Bundle应用导出成Jar文件，以便将它们部署到OSGi服务平台中。选择将要运行的Bundle应用，鼠标右键点击，在弹出菜单中，选择Run AS-->Equinox FrameWork来启动OSGi服务平台。在Equinox启动配置控制台中，可以为Bundle应用设置默认的Start Level和Bundle应用是否需要自动启动等选项。在本例中，为了讲解如何安装及启动Bundle应用，只将example Bundle应用设为自动启动，而exampleClient Bundle应用需要我们用命令安装及启动。

当OSGi Equinox FrameWork启动后，在OSGi控制命令台中输入ss命令，可以查看OSGi服务平台中已经安装的Bundle应用信息及其状态。如图4所示，可以看到当前OSGi服务平台中有两个Bundle处于Active状态，其中，system.bundle_3.2.0.v20060328为OSGi框架的系统Bundle，而example_1.0.0为注册姓名查询服务的Bundle应用，1.0.0为Bundle应用的版本号。

在OSGi控制命令台中利用install命令安装exampleClient Bundle应用，用ss命令查看安装后的Bundle应用信息及其状态。如图5所示：

在OSGi控制命令台中利用start命令安装exampleClient Bundle应用，用户可输入姓名，利用姓名查询服务来判断所输入姓名是否有效，用ss命令查看启动后的Bundle应用信息及其状态。如图6所示：

用户在在OSGi控制命令台中，可利用stop命令来停止指定的Bundle应用，close命令用来停止并退出OSGi控制命令台。关于OSGi Equinox FrameWork控制台命令的详细信息，可查看参考资料。

回页首

总结

OSGi服务框架提供了开放的、面向服务的、易于部署的编程模型，在构件面向服务为中心的企业应用的过程中，OSGi 技术正发挥越来越重要的作用。目前，Eclipse 3.2 体系架构是参照OSGi实现的，Equinox框架是 Eclipse 组织基于OSGi Release 4 的一个实现框架，它实现了OSGi 规范的核心框架和许多标准框架服务。在本文中，我们利用Eclipse 平台开发了两个Bundle应用，并且在Bundle应用中，声明、实现、注册并引用了一个简单的服务，最后，将Bundle应用部署到Equinox OSGi服务框架中。通过本文，读者可以了解如何开发和部署基于OSGi规范的Bundle应用。

回页首

下载

	关于下载方法的信息			Get Adobe® Reader®

回页首

参考资料

• OSGi Alliance。 http://www.osgi.org/。包含了OSGi Release 4的最新规范等信息。
  
  
• 在 Eclipse.org 中获得有关 Eclipse和Equinox的更多详细资料。
  

回页首

关于作者

		杨晓飞：目前在IBM中国软件开发试验室工作。软件工程师。 是WebSphere Portal 和Integrated Solutions Console Team的成员， 专注于Portal, Application Server, Integrated Solutons Console的研究。对企业自主运算(Autonomic Computing)，J2EE，SOA, OSGi 等有浓厚兴趣。E-mail: yangxiaofei2000@hotmail.com。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

[八进制]翻译原文地址: http://bjzhanghao.cnblogs.com/archive/2005/09/24/243312.html

原文地址：http://www.eclipsezone.com/articles/what-is-iadaptable/

IAdaptable在Eclipse里是一个非常重要的接口。对于Eclipse开发老手来说，它就像异常处理和抽象类一样寻常；但是对新手而言，它却令人感到困惑和畏惧。这篇文章将向你解释IAdaptable到底是什么，以及它在Eclipse里起到的作用。

类型转换

Java是所谓的强类型语言，也就是说，每个实例都对应一个类型。其实类型分为两种：声明类型和运行时类型（也分别被称为静态类型和动态类型）。像Python这样的弱类型语言常被称为无类型的语言，其实严格说来不是这样，因为每个实例都对应一个运行时类型，只是你并不需要声明这一点而已。

现在回到Java，为了能够执行一个类的某个方法，这个方法必须在声明类型中可见，换句话说，即使在运行时实例是某个子类型，你也只能执行那些父类型里定义的方法。

 

List list = new ArrayList();
list.add("data");       // 正确，add是List里定义的方法
list.ensureCapacity(4); // 不正确，ensureCapacity()只在ArrayList被定义

如果一定要执行特定类型的方法，我们必须先强制转换这个实例到正确的类型。对于上面的例子，我们可以将list转换为ArrayList（译注：原文In this case, we can cast ArrayList to List，怀疑是笔误），因为ArrayList实现了List接口，你甚至可以在运行时通过instanceof关键字检验list是否为ArrayList的一个实例。

可扩展的接口

不幸的是，一个类可能并没有实现你需要的接口，这样就无法进行强制类型转换了。原因有很多，比如只在少数情况下才需要这个接口，或者你需要的接口是在另一个不相关的库里，又或者接口是有了类以后才开发出来的，等等。

这时你就需要IAdaptable了。可以把IAdaptable想象为一个能够动态进行类型转换的途径。对比下面的直接类型转换：

 

Object o = new ArrayList();
List list = (List)o;

换一种方式，我们可以这样做：

 

IAdaptable adaptable = new ArrayList();//译注：这里的ArrayList应该不是指java.util.ArrayList 笨笨注: 这里应的ArrayList应该是一个实现了IAdaptable接口的自定义类, 这个类'兼容'java.util.List
List list = (List)adaptable.getAdapter(java.util.List.class);

这就是上面所说的动态类型转换，我们所做的事情是试图把adaptable转换为一个List实例。

那么，当可以直接转换的时候为什么要费这个力气通过getAdapter()来转换呢？其实这种机制可以让我们将目标类转换为它并没有实现的接口。举个例子，我们可能想把一个HashMap当作List来用，尽管这两个类的性质并不相同，可以这么做：

 

IAdaptable adaptable = new HashMap();//译注：这里的HashMap应该不是指java.util.HashMap  笨笨注: 这里应的HashMap应该是一个实现了IAdaptable接口的自定义类, 这个类'兼容'java.util.List
List list = (List)adaptable.getAdapter(java.util.List.class);

实现IAdaptable接口

大部分IAdaptable的实现是一些if语句的叠加，比如我们现在要实现HashMap的getAdapter()方法，它看起来可能是这样：

 

public class HashMap implements IAdaptable {
  public Object getAdapter(Class clazz) {
    if (clazz == java.util.List.class) {
      List list = new ArrayList(this.size());
      list.addAll(this.values());
      return list;
    }
    return null;
  }
  // 
}

所做的就是返回一个适配器（adapter，更确切的说是一个副本），而不是进行直接的类型转换。如果参数类型没有被支持，惯例是返回null值（而非抛出异常），代表这个方法失败了。因此，在调用这个方法时，不应该假定它总是返回非null值。

PlatformObject

当然，如果你希望增加一个新的被支持的adapter类型时必须编辑这个类才行（译注：在getAdapter()里增加更多的if语句），这会比较辛苦。而且，既然你已经知道了这个类型，何不直接修改接口声明呢？其实有很多原因使得你并不希望直接编辑这个类（例如更容易保持向下兼容性），也不想改变它的类型（HashMap虽然不是一个List，但可以转换过去）。

Eclipse通过PlatformObject抽象类来解决以上问题，它为你实现了IAdaptable接口，Eclipse平台（Platform）提供了IAdapterManager的一个实现，并且可以通过Platform.getAdapterManager()访问到，它把所有对getAdapter()的请求（调用）委托给一个名为IAdapterManager的东西。你可以将它想象为一个巨大的保存着类和adapter信息的Map，而PlatformObject的getAdapter()方法会查找这个Map。

适配已存在的类

这样，PlatformObject不需要重新编译就能够支持新的adapter类型，这一点在Eclipse里被大量使用以支持workspace的扩展点。

现在假设我们想要将一个只包含String类型元素的List转换为一个XMl节点，这个节点的格式如下：

 

<List>
  <Entry>First StringEntry>
  <Entry>Second StringEntry>
  <Entry>Third StringEntry>
List>

因为toString()方法可能有其他用途，我们不能通过覆盖toString()方法来实现这个功能。所以，我们要给List关联一个工厂类以处理XML节点类型的适配请求。要管理工厂类需要以下三个步骤：

1、由List生成一个Node，我们把这个转换过程用IAdapterFactory包装起来：

 

 

import nu.xom.*;
public class NodeListFactory implements IAdapterFactory {
  /**//* 可以转换到的类型 */
  private static final Class[] types = {
    Node.class,
  };
  public Class[] getAdapterList() {
    return types;
  }
  /**//* 转换到Node的功能代码 */
  public Object getAdapter(Object list, Class clazz) {
    if (clazz == Node.class && list instanceof List) {
      Element root = new Element("List");
      Iterator it = list.iterator();
      while(it.hasNext()) {
        Element item = new Element("Entry");
        item.appendChild(it.next().toString());
        root.appendChild(item);
      }
      return root;
    } else {
      return null;
    }
  }
}

2、把这个工厂类注册到Platform的AdapterManager，这样当我们希望从List的实例中获得一个Node实例时，就会找到我们的工厂类。注册一个工厂类的方式也很简单：

 

Platform.getAdapterManager().registerAdapters(
  new NodeListFactory(), List.class
);

这条语句将NodeListFactory关联到List类型。当从List里请求adapter时，Platform的AdapterManager会找到NodeListFactory，因为在后者的getAdapterList()方法的返回结果里包含了Node类，所以它知道从List实例得到一个Node实例是可行的。在Eclipse里，这个注册步骤一般是在plugin启动时完成的，但也可以通过org.eclipse.core.runtime.adapters扩展点来完成。

3、从List获得Node，下面是例子代码:

 

Node getNodeFrom(IAdaptable list) {
  Object adaptable = list.getAdapter(Node.class);
  if (adaptable != null) {
    Node node = (Node)adaptable;
    return node;
  }
  return null;
}

总结

综上所述，要在运行时为一个已有的类增加功能，所要做的只是定义一个用来转换的工厂类，然后把它注册到Platform的AdapterManager即可。这种方式在保持UI组件和非UI组件的分离方面特别有用。例如在org.rcpapps.rcpnews.ui和org.rcpapps.rcpnews这两个plugin里，前者的IPropertySource需要与后者的数据对象（data object）相关联，当前者初始化时，它将IPropertySource注册到Platform，当数据对象在导航器（navigator）里被选中的时候，属性视图里就会显示正确的属性。

显然，java.util.List并不是PlatformObject的子类，所以如果你希望能够编译这里所说的例子，必须建立一个List的子类型。注意，可以直接实现IAdaptable接口，而非必须继承PlatformObject抽象类。

 

public class AdaptableList implements IAdaptable, List {
  public Object getAdapter(Class adapter) {
     return Platform.getAdapterManager().getAdapter(this, adapter);
  }
  private List delegate = new ArrayList();
  public int size() {
    return delegate.size();
  }
  // 
}

最后，例子里生成XML的部分使用了XOM的类库.

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师