OSGi中应用资源加载委派反转机制的模块间资源加载方法

摘要

本发明涉及OSGi中应用资源加载委派反转机制的模块间资源加载方法，当移植到OSGi框架中的类库模块需要使用线程上下文类加载器加载位于应用模块中的资源时，在同步机制下，先获取当前线程运行堆栈中的类，并由类获取它们的类加载器，对取得的类加载器，只保留模块类加载器，并且重复的模块类加载器仅保留一个，然后根据预设的标志来确定资源所在的模块，最后将加载请求委派给资源所在模块的类加载器，由此，本发明解决了一些涉及应用运行上下文的类库移植到OSGi中不能正确加载资源的问题。

说明书

技术领域

本发明属于计算机领域,涉及到Java的类加载机制,更为具体地,涉及到OSGi中应用资源加载委派反转机制的模块间资源加载方法。

背景技术

软件模块化方法是当今最重要的软件技术之一。软件模块化采用分层或不分层但子模块独立的形式来降低软件系统的复杂度，使得系统的开发变得容易，提高了软件的生产效率；同时由于子模块的相对独立性，使得对于系统的维护也变得容易，提高了系统的可靠性。

软件模块化包含多种形式和相应的技术实现。在Java中，软件模块化最传统的形式就是类库，类库是指可能在多个工程中被重复使用的类的集合。而目前成熟的Java模块化框架则是OSGi（OpenService Gateway Initiative），它不仅支持模块化的概念，还支持软件模块的热插拔，即可以动态管理框架中的模块。

由于OSGi框架已经成为“事实上”的Java模块化标准，并且支持模块热插拔等功能，我们希望可以将类库移植到OSGi框架中去。一般来说，这样的移植工作只需要给原来的类库加上必要的元数据信息，使它们成为符合OSGi规范的模块。但是由于一些类库是作为应用的组成部分，在运行时会运行于应用的上下文中，具体来说，这些类库在运行时需要加载位于依赖它们的应用中的资源，这个加载过程会使用线程上下文类加载器去加载资源，若加载不成功，再使用加载本应用的类加载器去加载资源。但在OSGi中，模块之间是独立对等的，OSGi的每一个模块都有一个独立的类加载器，模块通过使用此类加载器来封装自身，同时，OSGi的规范未定义线程上下文类加载器，也就是说，OSGi标准框架的线程上下文类加载器会是默认的线程上下文类加载器，也就是系统类加载器。OSGi的这种源加载机制导致了这一类的类库在移植到OSGi框架中后不能正确加载资源。

对于此问题，目前只有针对具体类库的一些解决方案，它们或者需要分割应用模块，将相关资源移置到类库模块中，或者需要使用特定OSGi实现框架的属性，并且改变OSGi的类加载机制以使得类库模块可以加载位于依赖于它的应用模块中的资源。

发明内容

本发明的目的是提供一种模块间资源加载方法，此方法使用面向OSGi的资源加载委派反转机制在不改变应用模型以及OSGi本身的类加载机制的前提下，使移植到OSGi中的不同的类库模块能通过本发明的资源加载方法实现的类加载器并行地加载到位于应用模块中的资源。

为了达到上述目的，本发明提出的技术方案为：

OSGi中应用资源加载委派反转机制的模块间资源加载方法，包括：

a.提供一个使用本发明中的资源加载委派反转机制的类加载器作为线程上下文类加载器,并将原线程上下文类加载器设置为此类加载器的父类加载器;

b.对于需要使用线程上下文类加载器的类库模块以及资源所在的应用模块分别作标识，以选择是否使用本发明的资源加载方法加载资源，以及为本线程加载方法中的类加载器指明资源所在模块；

c.在OSGi框架中，若模块使用本发明的资源加载方法加载资源，则在线程上下文类加载器加载资源时，首先同步资源加载过程，在资源加载过程中，通过获取线程调用堆栈，以获取依赖于本模块的其它应用模块，然后根据模块的资源标识，将资源加载委派给相应模块的模块类加载器，以让资源所在的模块来加载资源。

本发明基于一个分析结果：类库模块在使用线程上下文类加载器时，资源一定在此时运行栈中的某个类所在的模块里。分析过程如下：

类库模块的BundleActivator属性为空，也就是说它本身不能作为程序的入口。需要使用类库模块的应用模块需要导入类库模块导出的包，在使用类库模块时，则是由使用类库模块的应用模块来调用类库模块的API来完成。因而对于当前线程来说，其调用顺序一定是：应用模块中的某些类直接或间接地调用类库模块中的某些类，以运行类库模块，然后类库模块中的相应类再调用线程上下文类加载器去加载资源。故在当前的线程调用堆栈中，包含资源的应用模块的某些类位于线程上下文类加载器类的下面，也就是说此时资源位于运行栈中的某些类所在的模块中。

本发明中资源加载委派反转机制的说明：

本发明在上面的分析中可知，应用模块需要导入类库模块的相关类、包。结合OSGi的类加载机制和附图1，可以说，相对于类库模块来说，应用模块对某些类的加载会委派给类库模块，其加载委派方向就是附图1中的实线箭头方向。而类库模块并未导入应用的包，当它需要加载位于应用中的资源时，需要按虚线方向将加载请求委派给应用模块。这个委派过程是由线程上下文类加载器来完成的。由于它与实际的委派方向相反，故称之为资源加载委派反转机制。

综上所述，本发明提出的线程上下文类加载器，在加载资源时，首先同步加载过程，然后通过对线程堆栈的分析，将资源加载请求委派给资源所在模块，从而可以在不破坏OSGi类加载机制、不破坏应用与类库模型的前提下，使运行于OSGi中的类库可以并行地加载位于应用中的资源，解决了这一类类库不能正确加载资源的问题。

附图说明

图1为本发明中的资源加载委派反转机制原理图。

图2为本发明的线程上下文类加载器加载资源流程。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将给合附图2对本发明作进一步的详细描述。

本发明的核心思想是：当类库模块在使用本发明的线程上下文类加载器加载资源时，获取程序当前的运行堆栈，通过此堆栈中的类来获取当前的模块调用关系，然后再根据标识信息，得到依赖于类库模块的资源所在的应用模块，并将对资源的加载请求委派给此模块的类加载器。

本发明中的资源加载方法所在的类加载器，需先设置其父类加载器为原线程上下文类加载器，然后将此类加载器设置为当前的线程上下文类加载器。

图2为本发明资源加载方法中使用的类加载器使用资源加载委派反转机制在模块间加载资源的过程流程图。具体步骤如下：

（1）判断是否标识使用本机制，若使用，则转（2），否则使用父类加载器加载；

（2）取得资源同步锁；

（3）检查系统是否使用安全管理器，若使用，则以特权模式执行

（4）否则直接执行（4）；

（4）获取当前线程执行堆栈中的类；

（5）对每个类，获取它的类加载器；

（6）分析类加载器，只保留OSGi模块的类加载器，同时对于连续相同的类加载器，只保留一个，以得到运行于当前线程中的模块堆栈；

（7）遍历此模块堆栈，将含有资源标识的模块的模块类加载器放入委派目标队列中；

（8）判断委派目标队列是否含有模块类加载器对象，若没有，则转（10）；

（9）将加载请求依次委派给队列中的模块类加载器；若有加载成功，转（11）；

（10）使用父类加载器去加载资源，若加载失败，则表示加载过程失败；

（11）清空委派目标队列，并释放资源同步锁。

部分流程的说明如下：

流程（1）、（7）中的标识，使用OSGi的MANIFEST头文件来定义，分别定义为TCLDelegate、TCLResource属性。

流程（2）中取得资源同步锁，由于系统中只存在一个线程上下文类加载器，故通过对本类加载器同步来保证此加载过程的同步性。

流程（3）中使用特权模式以突破安全管理器的限制，而特权模式的实现是通过让资源加载方法的类加载器去继承PrivilegedAction接口，将特权方法放在本类加载器继承的接口方法中来完成。

流程（4）中的取得当前运行栈中的类是通过使用一个类继承SecurityManager类，并在此类的方法中去调用SecurityManager的getClassContext方法来完成。

以上所述，仅是本发明的实施例，并非对本发明作任何限制，凡是依据本发明的技术实质对以上实施例所作的任何简单修改、变更以及等效步骤变化，均属于本发明技术方案的保护范围。