打造一个基于OSGi的Web Application -

chengxuetao

浏览: 1590622 次
性别:

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

打造一个基于OSGi的Web Application

博客分类：

OSGi

OSGi技术发展至今也有好几年了，然而除了在富客户端应用(以Eclipse为代表)和服务器应用(如大多数的应用服务器)方面大放光芒之外，在 Web Application方面的应用和资料却少之又少。一方面，在OSGi规范中，对于Web应用方面的规划尚不成熟，即使在最新的4.2版中，也仅仅只有一个HttpService，这个简陋的service甚至不能覆盖任何一个现有的Servlet规范；另一方面，各个OSGi实现厂商对 HttpService的实现也是不完全的，在开发实现一个常规的Web Application时，这些实现也是完全不够用的。本文章的目的，也就是为了探索OSGi在Web Application上的开发之路该如何走，从我的视角提出一些看法，做一些尝试，希望对大家有所帮助。

现在OSGi与Web Application的结合，大致有两个方向：

OSGi包含Web Container：目前能完美嵌入OSGi的Web Container似乎只有jetty一个，tomcat的catalina似乎有希望能成为第二个。我们完全不能指望Websphere和 Weblogic能在短期内具有能嵌入OSGi的能力，所以这个方向理所当然的被我放弃了。
Web Container包含OSGi：这个方面目前只有equinox的Servlet Bridge这么一个著名的实现，equinox通过Servlet Bridge的方式来实现一个OSGi的HttpService服务，这个服务目前能做的事情还非常有限，还不足以覆盖Servlet规范。

我的目标是构建一个OSGi与Web Application结合的方式，它要能满足一下几点需求：

基于OSGi的bundle和service。
适合绝大对数支持Servlet 2.4和Jsp 2.0规范的Web服务器。
适合现有的实现OSGi 4.2规范的OSGi Framework实现：equinox、felix和knopflerfish。
支持大部分Servlet 2.4和Jsp 2.0规范中声明的功能。
提供一个基于HttpService的服务实现，以此来兼容其他使用HttpService的service。

毫无疑问，我将采用Web Container中包含OSGi的方式来实现，具体的内容将在以后陆续提供。

搭建开发环境

工欲善其事必先利其器，在正式开发之前，花一点时间来构建开发环境还是有必要的。本章介绍一下我的开发环境。

我使用的开发环境如下：

Eclipse：当然了，最新版3.52，其中包含了最新版的WTP(Eclipse Web Tools Platform)，个人感觉，不比MyEclipse差，而且最重要的是，它是free的。
equinox-SDK：版本为3.6M5，实现了OSGi R4 core framework specification 4.2。
Tomcat：作为第一个实现的Web Container，我采用了Tomcat，从中抽取几个特定版本作为测试对象：5.5.28和6.0.26这两个版本，因为他们支持Java5和 Servlet2.4/Jsp2.0。
JDK：当然Java5以上的，谁叫Equinox只支持Java5以上的呢，我采用的是jdk1.5.0.22。基于Websphere和 Weblogic的缓慢的JDK升级历程，我还是决定不采用Java6或者是7了。

以下是我的目录结构：

环境整合：
1.运行Eclipse，指定Workspace路径为：D:/dbstar/workspaces/OSGi
2.设置Plug-in Development的Target Platform，增加equinox-SDK-3.6M5并设为默认，这样我们就可以使用equinox-SDK-3.6M5来作为我们开发 bundle的基准库，而不是使用Eclipse自带的plugin开发环境。

3.在Server配置中增加Tomcat两个版本的服务器。

自此，我的开发环境就已经设置好了，当然了，还有一些其他的个人习惯设置，比如说字体，默认编码设为UTF-8，Code Template和Formatter等等，就不一一赘述了。

在下面一篇中，将介绍如何在Web Application中启动OSGi。

在WebApplication中启动 OSGi

本章将创建一个Web Application项目，并描述如何在此应用中启动OSGi。

首先，在Eclipse中创建一个Dynamic Web Project，名字为OSGi-Web，Context root为osgi。

这个项目只作为部署Web Application使用，相关java代码放在另外一个Java Project中，因此我们再创建一个新的Java Project，名字为OSGi-Web-Launcher。然后在OSGi-Web项目的Java EE Module Dependencies中设置OSGi-Web-Launcher为关联，这样在部署的时候，OSGi-Web-Launcher项目中的java代码将为打包为jar存放到Web的WEB-INF/lib目录之中。

为了启动OSGi，我们在web中增加一个ServletContextListener监听器实现，并且通过这个监听器来控制OSGi容器的启动和终止。

在OSGi-Web-Launcher项目中增加一个java类，类名为FrameworkConfigListener，实现接口 ServletContextListener，package为org.dbstar.osgi.web.launcher。在 contextInitialized方法中，增加启动OSGi的代码，在contextDestroyed方法中，增加停止OSGi的代码，这样我们就可以使OSGi容器的生命周期与ServletContext的生命周期保持一致了。

启动OSGi容器：
感谢OSGi规范4.2给了我们一个简单统一的启动OSGi容器的方式，所有实现OSGi4.2规范的容器实力都应该实现这种启动方式，那就是通过 org.osgi.framework.launch.FrameworkFactory，同时，还必须在其实现jar中放置一个文件：META- INF/services/org.osgi.framework.launch.FrameworkFactory，这个文件中设置了实际的 FrameworkFactory实现类的类名。在equinox-SDK-3.6M5的 org.eclipse.osgi_3.6.0.v20100128-1430.jar中，这个文件的内容是：org.eclipse.osgi.launch.EquinoxFactory。

我们先写一个工具类来载入这个配置文件中的内容：

1 package org.dbstar.osgi.web.launcher;
2
3 import java.io.BufferedReader;
4 import java.io.IOException;
5 import java.io.InputStream;
6 import java.io.InputStreamReader;
7
8 public abstract class ServiceLoader{
9 public final static < E > Class < E > load(Class < E > clazz) throws IOException,ClassNotFoundException{
10 return load(clazz,Thread.currentThread().getContextClassLoader());
11 }
12
13 @SuppressWarnings( " unchecked " )
14 public final static < E > Class < E > load(Class < E > clazz,ClassLoaderclassLoader) throws IOException,
15 ClassNotFoundException{
16 Stringresource = " META-INF/services/ " + clazz.getName();
17 InputStreamin = classLoader.getResourceAsStream(resource);
18 if (in == null ) return null ;
19
20 try {
21 BufferedReaderreader = new BufferedReader( new InputStreamReader(in));
22 StringserviceClassName = reader.readLine();
23 return (Class < E > )classLoader.loadClass(serviceClassName);
24 } finally {
25 in.close();
26 }
27 }
28 }

然后获取到FrameworkFactory的实例类：

1 try {
2 frameworkFactoryClass = ServiceLoader.load(FrameworkFactory. class );
3 } catch (Exceptione){
4 throw new IllegalArgumentException( " FrameworkFactoryserviceloaderror. " ,e);
5 }
6 if (frameworkFactoryClass == null ){
7 throw new IllegalArgumentException( " FrameworkFactoryservicenotfound. " );
8 }

实例化FrameworkFactory：

1 FrameworkFactoryframeworkFactory;
2 try {
3 frameworkFactory = frameworkFactoryClass.newInstance();
4 } catch (Exceptione){
5 throw new IllegalArgumentException( " FrameworkFactoryinstantiationerror. " ,e);
6 }

获取Framework的启动配置：

1 Map < Object,Object > configuration;
2 try {
3 // 载入Framework启动配置
4 configuration = loadFrameworkConfig(event.getServletContext());
5 if (logger.isInfoEnabled()){
6 logger.info( " LoadFrameworkconfiguration:[ " );
7 for (Objectkey:configuration.keySet()){
8 logger.info( " /t " + key + " = " + configuration.get(key));
9 }
10 logger.info( " ] " );
11 }
12 } catch (Exceptione){
13 throw new IllegalArgumentException( " LoadFrameworkconfigurationerror. " ,e);
14 }

启动配置读取外部配置文件，可以在此配置文件中增加OSGi容器实现类相关的配置项，例如Equinox的osgi.console：

1 // 载入Framework启动配置
2 private static Map < Object,Object > loadFrameworkConfig(ServletContextcontext) throws MalformedURLException{
3 StringconfigLocation = context.getInitParameter(CONTEXT_PARAM_OSGI_CONFIG_LOCATION);
4 if (configLocation == null )configLocation = DEFAULT_OSGI_CONFIG_LOCATION;
5 else if ( ! configLocation.startsWith( " / " ))configLocation = " / " .concat(configLocation);
6
7 Propertiesconfig = new Properties();
8 try {
9 // 载入配置项
10 config.load(context.getResourceAsStream(configLocation));
11 if (logger.isInfoEnabled())logger.info( " LoadFrameworkconfigurationfrom: " + configLocation);
12 } catch (IOExceptione){
13 if (logger.isWarnEnabled())logger.warn( " LoadFrameworkconfigurationerrorfrom: " + configLocation,e);
14 }
15
16 StringstorageDirectory = config.getProperty(PROPERTY_FRAMEWORK_STORAGE,DEFAULT_OSGI_STORAGE_DIRECTORY);
17 // 检查storageDirectory合法性
18 if (storageDirectory.startsWith(WEB_ROOT)){
19 // 如果以WEB_ROOT常量字符串开头，那么相对于WEB_ROOT来定位
20 storageDirectory = storageDirectory.substring(WEB_ROOT.length());
21 storageDirectory = context.getRealPath(storageDirectory);
22 } else {
23 // 如果是相对路径，那么相对于WEB_ROOT来定位
24 if ( ! new File(storageDirectory).isAbsolute()){
25 storageDirectory = context.getRealPath(storageDirectory);
26 }
27 }
28 storageDirectory = new File(storageDirectory).toURL().toExternalForm();
29 config.setProperty(PROPERTY_FRAMEWORK_STORAGE,storageDirectory);
30 if (logger.isInfoEnabled())logger.info( " UseFrameworkStorage: " + storageDirectory);
31
32 return config;
33 }

然后，就可以获取framework实例了，通过framework来初始化，启动和停止OSGi容器：

1 try {
2 framework = frameworkFactory.newFramework(configuration);
3 framework.init();
4
5 // 初始化Framework环境
6 initFramework(framework,event);
7
8 // 启动Framework
9 framework.start();
10
11 succeed = true ;
12 } catch (BundleExceptione){
13 throw new OSGiStartException( " StartOSGiFrameworkerror! " ,e);
14 } catch (IOExceptione){
15 throw new OSGiStartException( " InitOSGiFrameworkerror " ,e);
16 }

在initFramework方法中，主要做两件事情，一是将当前的ServletContext作为一个service注册到OSGi容器中去：

1 private static void registerContext(BundleContextbundleContext,ServletContextservletContext){
2 Propertiesproperties = new Properties();
3 properties.setProperty( " ServerInfo " ,servletContext.getServerInfo());
4 properties.setProperty( " ServletContextName " ,servletContext.getServletContextName());
5 properties.setProperty( " MajorVersion " ,String.valueOf(servletContext.getMajorVersion()));
6 properties.setProperty( " MinorVersion " ,String.valueOf(servletContext.getMinorVersion()));
7 bundleContext.registerService(ServletContext. class .getName(),servletContext,properties);
8 }

第二件事就是：在第一次初始化容器时，加载并启动指定目录中的bundle：

1 // 初始化Framework环境
2 private static void initFramework(Frameworkframework,ServletContextEventevent) throws IOException{
3 BundleContextbundleContext = framework.getBundleContext();
4 ServletContextservletContext = event.getServletContext();
5
6 // 将ServletContext注册为服务
7 registerContext(bundleContext,servletContext);
8
9 Filefile = bundleContext.getDataFile( " .init " );
10 if ( ! file.isFile()){ // 第一次初始化
11 if (logger.isInfoEnabled())logger.info( " InitFramework

" );
12
13 StringpluginLocation = servletContext.getInitParameter(CONTEXT_PARAM_OSGI_PLUGINS_LOCATION);
14 if (pluginLocation == null )pluginLocation = DEFAULT_OSGI_PLUGINS_LOCATION;
15 else if ( ! pluginLocation.startsWith( " / " ))pluginLocation = " / " .concat(pluginLocation);
16
17 // 安装bundle
18 FilebundleRoot = new File(servletContext.getRealPath(pluginLocation));
19 if (bundleRoot.isDirectory()){
20 if (logger.isInfoEnabled())logger.info( " LoadFrameworkbundlesfrom: " + pluginLocation);
21
22 FilebundleFiles[] = bundleRoot.listFiles( new FilenameFilter(){
23 public boolean accept(Filedir,Stringname){
24 return name.endsWith( " .jar " );
25 }
26 });
27
28 if (bundleFiles != null && bundleFiles.length > 0 ){
29 for (FilebundleFile:bundleFiles){
30 try {
31 bundleContext.installBundle(bundleFile.toURL().toExternalForm());
32 if (logger.isInfoEnabled())logger.info( " Installbundlesuccess: " + bundleFile.getName());
33 } catch (Throwablee){
34 if (logger.isWarnEnabled())logger.warn( " Installbundleerror: " + bundleFile,e);
35 }
36 }
37 }
38
39 for (Bundlebundle:bundleContext.getBundles()){
40 if (bundle.getState() == Bundle.INSTALLED || bundle.getState() == Bundle.RESOLVED){
41 if (bundle.getHeaders().get(Constants.BUNDLE_ACTIVATOR) != null ){
42 try {
43 bundle.start(Bundle.START_ACTIVATION_POLICY);
44 if (logger.isInfoEnabled())logger.info( " Startbundle: " + bundle);
45 } catch (Throwablee){
46 if (logger.isWarnEnabled())logger.warn( " Startbundleerror: " + bundle,e);
47 }
48 }
49 }
50 }
51 }
52
53 new FileWriter(file).close();
54 if (logger.isInfoEnabled())logger.info( " Frameworkinited. " );
55 }
56 }

以上就是启动OSGi容器的过程，相比较而言，停止容器就简单多了：

1 public void contextDestroyed(ServletContextEventevent){
2 if (framework != null ){
3 if (logger.isInfoEnabled())logger.info( " StoppingOSGiFramework

" );
4
5 boolean succeed = false ;
6 try {
7 if (framework.getState() == Framework.ACTIVE)framework.stop();
8 framework.waitForStop( 0 );
9 framework = null ;
10
11 succeed = true ;
12 } catch (BundleExceptione){
13 throw new OSGiStopException( " StopOSGiFrameworkerror! " ,e);
14 } catch (InterruptedExceptione){
15 throw new OSGiStopException( " StopOSGiFrameworkerror! " ,e);
16 } finally {
17 if (logger.isInfoEnabled()){
18 if (succeed)logger.info( " OSGiFrameworkStopped! " );
19 else logger.info( " OSGiFrameworknotstop! " );
20 }
21 }
22 }
23 }

最后，还有一件事情，就是将FrameworkConfigListener配置到web.xml中：

1 
2 < listener >
3 < listener-class > org.dbstar.osgi.web.launcher.FrameworkConfigListener </ listener-class >
4 </ listener >

让我们来测试一下吧，在Eclipse中新建一个Server：

另外，在OSGi-Web-Launcher项目的classpath中增加 org.eclipse.osgi_3.6.0.v20100128-1430.jar，并且在Java EE Module Dependencies中勾选这个jar，这样可以保证这个jar最终部署到Web Application的WEB-INF/lib目录下去。同样，还需要增加commons-logging.jar。

然后就可以启动这个Server查看效果了。

附上本文中提到的源代码。

为OSGi容器提供Web Application环境

本章叙述如何在OSGi容器中提供必要的Web Application环境，其中包括Servlet 2.4、Jsp 2.0和Commons-Logging相关的package，使得其他在OSGi容器中的bundle可以import。

为了在OSGi容器中提供export的package，一般有三种方式：

一个常规的bundle，自身包含必要的class，同时在Export-Package中声明。
一个Host为System Bundle的Fragment Bundle，同样也可以在Export-Package中声明导出的package，只要这个package中的class在System Bundle的ClassLoader中能load到。
通过启动Framework的配置项：org.osgi.framework.system.packages和 org.osgi.framework.system.packages.extra。OSGi 4.2规范中描述了这两个标准的配置项。在这两个配置项中描述的package都等同于在System Bundle中声明了export。

对于在Web Application中运行的OSGi容器，一些必要的环境是通过Web Container提供的，我们最好不要，也不应该用自己的类来替换，这包括了j2ee相关的jar，如servlet和jsp相关的jar等等。在一些 WebServer的实现中，会自动屏蔽Web Application的classpath中的j2ee相关的jar。

除了j2ee相关的jar之外，还有一些使用非常普遍的jar，比如说Apache commons一类，其中最常用的大概就是commons-lang.jar、commons-io.jar和commons-logging.jar 了，这些jar最好也有Web Container来提供，或者有必要的话，在Web Application中提供，而不是在OSGi容器中提供，这涉及到一些JVM层次的单例类，或者希望能由Web Application级别来统一实现和配置的环境，最常见的应用就是日志配置了。通过由Web Application提供的commons-logging来给OSGi容器中的环境使用，而commons-logging通过何种方式来实现，不需要让OSGi内部知道。

至于导出package到OSGi的方式中，是采用第二种还是第三种，主要区别在于：第三种方式是加载framework时指定的，在其后的生命周期中不可更改，而第二种方式则更符合OSGi动态加载的特性。

我采用第二种方式来给OSGi容器增加环境支持，具体操作很简单，以Servlet为例，首先编写一个文本文件，名字为：MANIFEST.MF，内容如下：

注意其中关键的header属性，Fragment-Host: system.bundle; extension:=framework
这样写才能保证这个Fragment Bundle在各种OSGi Framework实现中都能兼容。
保存以后，将这个文件放置到一个名字为META-INF的目录中，然后用jar命令打包成一个jar即可(或者用winrar打包，记得选择压缩方式为 zip，在打包后将zip后缀名改成jar，我通常都是这么干的)。

Jsp的MANIFEST.MF：

1 Manifest-Version: 1.0
2 Bundle-ManifestVersion: 2
3 Bundle-Name:JspExtensionFragment
4 Bundle-SymbolicName:javax.servlet.jsp_extension ; singleton:=true
5 Bundle-Version: 2.0.0
6 Bundle-Vendor:dbstar
7 Fragment-Host:system.bundle ; extension:=framework
8 Bundle-RequiredExecutionEnvironment:J2SE- 1.5
9 Export-Package:javax.servlet.jsp ; version="2.0.0",
10 javax.servlet.jsp.el ; version="2.0.0",
11 javax.servlet.jsp.resources ; version="2.0.0",
12 javax.servlet.jsp.tagext ; version="2.0.0"

commons-logging的MANIFEST.MF

因为我用的是commons-logging-1.1.1.jar，所以version写的是1.1.1，大家可以修改成自己所使用的jar的版本。

将上面生成的三个jar放到OSGi-Web项目的WEB-INF/osgi/plugins目录下面。还记得我在上一章创建的那个Tomcat Server么，clean一次，新的jar会部署到Tomcat中去，然后就可以运行Server了。
至于为什么是clean而不是publish，区别在于clean会清除所有OSGi容器创建出来的文件，这样下次启动OSGi时就会做一个 install bundle的事情，而publish不会自动install新加进去的bundle。

如果你使用的是equinox，那么你可以在控制台中看到Syetem Bundle现在多了几个Fragments，查看一下Servlet Bundle，会显示下列信息，表示servlet 2.4的package在OSGi容器中已经可用了：

osgi>bundle 2
javax.servlet_extension_2 .4.0 [ 2 ]
Id = 2 , Status = RESOLVEDDataRoot = D:/dbstar/workspaces/OSGi/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/OSGi-Web/WEB-INF/osgi/configuration/org.eclipse.osgi/bundles/ 2 /data
Noregisteredservices.
Noservicesinuse.
Exportedpackages
javax.servlet ; version="2.4.0"[exported]
javax.servlet.http ; version="2.4.0"[exported]
javax.servlet.resources ; version="2.4.0"[exported]
Noimportedpackages
Hostbundles
org.eclipse.osgi_3 .6.0 .v20100128- 1430 [ 0 ]
Nonamedclassspaces
Norequiredbundles

最后提供几个本章提到的bundle给大家下载，大家就不用自己再起生成一个了。
javax.servlet_extension_2.4.0.jar
javax.servlet.jsp_extension_2.0.0.jar
org.apache.commons.logging_extension_1.1.1.jar
系统不让传扩展名为.jar的文件，大家下载后把扩展名改改吧，阿门。

在OSGi容器中管理Web元素的实现思路

要在OSGi容器中动态的管理Web相关的元素，目前有两种方式。

一种是通过类似于bridge的方式，现在外层的Web Application中配置一个对应的元素，然后通过对这个元素将外部的访问桥接到OSGi容器内部。在OSGi容器内部，会有一个总控的 service，通过这个service来提供Web元素的动态管理，以及对外界请求的响应和分发。Equinox的Servlet Bridge就是采用的这种方式。

另一种方式就是通过使用Web Container提供的原生的API来实现Web元素的动态管理，将Web Container的部分功能作为Service注册到OSGi中，然后在OSGi中通过这个Service来动态的管理Web元素。

两种方式各有利弊：

对于bridge方式来说，优点是与Web Container实现无关，在多种Web Container中均能正常使用；缺点也很明显，无法使用Web Container提供的各种特性，并且相当于自己要实现一部分Web Server的功能，不仅是重复造轮子，而且还是个不怎么好的轮子，能否满足企业级应用的需求，还只是个未知数。

对于使用原生API的方式来说，优点就是完全使用Web Server自身的机制，可以保证性能和功能需求；缺点同样也很明显，现在流行的Web Server开源的并不多，而且就算是开源的，也不一定提供了可以动态管理Web元素的API，就算是有相应的API，也不一定适合OSGi环境，而且同一个Web Server的不同版本，API也很有可能会变化，这直接导致了原生方式实现的多样性和不兼容性。

幸运的是，在Tomcat 5.5.x和6.0.x中都提供了这样的API，在以后的章节中，我会着重针对Tomcat 5.5.x、6.0.x版本以及对bridge方式这三个场景，来实现对Web元素的动态管理。

Servlet 2.4中描述了如下可以在web.xml中配置的元素，这也是我要实现动态管理的目标：

Context Parameter
Error Page
Filter
Filter Mapping
Listener
Security role
Servlet
Servlet Mapping
Welcome Page

增加日志输出功能

到目前为止，我们的基于OSGi内核的Web Application还没有任何的日志输出功能，本章将介绍如何在这个Web应用中配置和输出日志。

在前面的配置中，我们的应用中只含有commons-logging.jar，而OSGi容器之外的代码中，均是通过配置commons logging的Log对象来输出日志的，在默认的配置下，系统将采用Jdk14Logger来作为输出日志的实现，这对我们来说是远远不够的。我们下一步将配置更加常用的Log4j在作为我们的日志输出实现，通过以下几个步骤：

一、为Web Application配置Log4j：
1.在OSGi-Web项目的Java EE Module Dependencies中，增加对log4j.jar的依赖关系。
2.在WEB-INF/config目录中，增加一个log4j.properties文件，内容如下：

1 ###directlogmessagestostdout###
2 log4j.appender.stdout = org.apache.log4j.ConsoleAppender
3 log4j.appender.stdout.Target = System.out
4 log4j.appender.stdout.layout = org.apache.log4j.PatternLayout
5 log4j.appender.stdout.layout.ConversionPattern =% d{ABSOLUTE} % 5p % c{ 1 }: % L - % m % n
6
7 #DefaultLogFileConfigurationForOSGi
8 log4j.appender.OSGiLog = org.apache.log4j.DailyRollingFileAppender
9 log4j.appender.OSGiLog.DatePattern = ' . ' yyyy - MM - dd
10 log4j.appender.OSGiLog.File = ${osgi.root} / logs / OSGi.log
11 log4j.appender.OSGiLog.layout = org.apache.log4j.PatternLayout
12 log4j.appender.OSGiLog.layout.ConversionPattern =% d[ % t] %- 5p % c - % m % n
13
14 log4j.rootLogger = info,stdout
15
16 log4j.logger.org.dbstar = debug,OSGiLog
17 log4j.logger.org.eclipse = debug,OSGiLog

3.采用Spring Web的Log4j配置方式，在web.xml中增加如下配置：

1 
2 < context-param >
3 < param-name > webAppRootKey </ param-name >
4 < param-value > osgi.root </ param-value >
5 </ context-param >
6 < context-param >
7 < param-name > log4jConfigLocation </ param-name >
8 < param-value > /WEB-INF/config/log4j.properties </ param-value >
9 </ context-param >
10
11 
12 < listener >
13 < listener-class > org.springframework.web.util.Log4jConfigListener </ listener-class >
14 </ listener >

4.在OSGi-Web项目的Java EE Module Dependencies中，增加spring相关jar的依赖。

经过以上4个步骤，我们在Web Application中使用commons logging输出的日志，都可以通过Log4j来显示了。但是作为OSGi容器内部来说，这还不够。OSGi规范中推荐使用 org.osgi.service.log包中的LogService和LogReaderService来管理和显示OSGi日志。为了能正常显示 OSGi容器内部的日志，我们还需要将LogService、LogReaderService和OSGi容器外部的Log4j结合起来才行，为了达到这个目的，我们还需要做以下几个步骤：
1.为OSGi容器增加一个org.osgi.service.log的实现包。在equinox-SDK-3.6M5开发包中，这个实现jar 是：org.eclipse.equinox.log_1.2.100.v20100118.jar，当然，还需要 org.eclipse.osgi.services_3.2.100.v20100108.jar，都放置到OSGi-Web工程的WEB- INT/osgi/plugins目录下面。
2.为OSGi容器增加Declarative Services支持。在equinox-SDK-3.6M5开发包中，包含了一个DS的实现：org.eclipse.equinox.ds_1.2.0.v20100125.jar，将这个jar和一个依赖的 jar：org.eclipse.equinox.util_1.0.100.v20090520-1800.jar部署到OSGi容器中，就可以使用 DS服务了。同样也放到plugins目录下面去。
3.新增一个plugin工程，名字为：org.dbstar.osgi.log，我们使用DS方式来获取服务，相关源代码如下：
OSGI-INF/log.xml

1 <? xmlversion="1.0"encoding="UTF-8" ?>
2 < scr:component xmlns:scr ="http://www.osgi.org/xmlns/scr/v1.1.0" enabled ="true" name ="logListener" xsi:schemaLocation ="http://www.osgi.org/xmlns/scr/v1.1.0http://www.osgi.org/xmlns/scr/v1.1.0/scr.xsd" >
3 < implementation class ="org.dbstar.osgi.log.LogListenerImpl" />
4 < reference cardinality ="1..1" interface ="org.osgi.service.log.LogReaderService" name ="LogReaderService" policy ="static" />
5 </ scr:component >

LogListenerImpl.java

1 package org.dbstar.osgi.log;
2
3 import org.apache.commons.logging.Log;
4 import org.apache.commons.logging.LogFactory;
5 import org.osgi.service.component.ComponentContext;
6 import org.osgi.service.log.LogEntry;
7 import org.osgi.service.log.LogListener;
8 import org.osgi.service.log.LogReaderService;
9 import org.osgi.service.log.LogService;
10
11 public class LogListenerImpl implements LogListener{
12 private static final Loglogger = LogFactory.getLog(LogListenerImpl. class );
13
14 protected void activate(ComponentContextcontext){
15 LogReaderServiceservice = (LogReaderService)context.locateService( " LogReaderService " );
16 service.addLogListener( this );
17 }
18
19 protected void deactivate(ComponentContextcontext){
20 LogReaderServiceservice = (LogReaderService)context.locateService( " LogReaderService " );
21 service.removeLogListener( this );
22 }
23
24 public void logged(LogEntryentry){
25 Stringmsg = getMessage(entry);
26
27 switch (entry.getLevel()){
28 case LogService.LOG_DEBUG:
29 if (logger.isDebugEnabled()){
30 if (entry.getException() == null ){
31 logger.debug(msg);
32 } else {
33 logger.debug(msg,entry.getException());
34 }
35 }
36 break ;
37 case LogService.LOG_INFO:
38 if (logger.isInfoEnabled()){
39 if (entry.getException() == null ){
40 logger.info(msg);
41 } else {
42 logger.info(msg,entry.getException());
43 }
44 }
45 break ;
46 case LogService.LOG_WARNING:
47 if (logger.isWarnEnabled()){
48 if (entry.getException() == null ){
49 logger.warn(msg);
50 } else {
51 logger.warn(msg,entry.getException());
52 }
53 }
54 break ;
55 case LogService.LOG_ERROR:
56 if (logger.isErrorEnabled()){
57 if (entry.getException() == null ){
58 logger.error(msg);
59 } else {
60 logger.error(msg,entry.getException());
61 }
62 }
63 break ;
64 }
65 }
66
67 private StringgetMessage(LogEntryentry){
68 StringBuildermsg = new StringBuilder();
69 if (entry.getBundle() != null )msg.append( " [bundle: " ).append(entry.getBundle()).append( " ] " );
70 if (entry.getServiceReference() != null )msg.append( " [service: " ).append(entry.getServiceReference())
71 .append( " ] " );
72 msg.append(entry.getMessage());
73 return msg.toString();
74 }
75 }

META-INF/MANIFEST.MF

1 Manifest-Version: 1.0
2 Bundle-ManifestVersion: 2
3 Bundle-Name:LogBundle
4 Bundle-SymbolicName:org.dbstar.osgi.log
5 Bundle-Version: 1.0.0
6 Bundle-Vendor:dbstar
7 Bundle-RequiredExecutionEnvironment:J2SE- 1.5
8 Service-Component:OSGI-INF/log.xml
9 Import-Package:org.apache.commons.logging ; version="1.0.4",
10 org.osgi.framework ; version="1.3.0",
11 org.osgi.service.component ; version="1.1.0",
12 org.osgi.service.log ; version="1.3.0"

好了，打包成bundle jar然后也扔到plugins目录下面，然后clean一下server，启动，现在能看到多了许多日志输出，现在OSGi内部通过 LogService输出的日志也能由Log4j接管了。

最后总结一下，LogService和LogReaderService是OSGi规范中提倡的日志标准，在equinox内部实现中大量使用了这种日志，而commons logging是我们开发常规程序时所常用的日志方式。在你的bundle代码中，具体要采用哪一种日志方式，并没有强制的要求，大家可以根据各人喜好来选用。
顺便提一句，LogService有些美中不足的是，不能像commons logging那样，显示出日志具体是从哪个java类的第几行输出的，不知道各位大虾是否有人知道该如何解决呢，希望不吝赐教：）

设置初始化bundle的 StartLevel

后来发现其中在初始化时加载bundle的方式，还有一些美中不足。这种方式加载的bundle都具有相同的启动顺序，即bundle的初始化默认 start level，在之前均没有做过特别的设置，所以默认值都是1，这样会导致所有的bundle的启动顺序无法控制，在某些希望特殊bundle优先加载的场合(如日志功能，需要最先加载)，我们希望能够在bundle初始化的时候就能指定特别的start level，这样所有的bundle就能按照我们预设的启动顺序来加载了。下面就是我优化过的初始化代码，能够解决启动顺序问题。

工作原理是这样的，首先，在原来存放初始化bundle的目录，也就是OSGi-Web工程的/WEB-INF/osgi/plugins目录下面再增加一个名为start的目录，在start目录下，再按照期望设置的start level来建立子目录，例如，期望设置start level为1的bundle，放到plugins/start/1目录下面；期望设置start level为2的bundle，放到plugins/start/2目录下面，以此类推。

代码方面，设置bundle的start level，需要使用StartLevel Service，可以通过下面代码获得：

1 // StartLevelService，用于设置bundle的 startlevel
2 ServiceReferenceslRef = bundleContext.getServiceReference(StartLevel. class .getName());
3 StartLevelsl = slRef == null ? null :(StartLevel)bundleContext.getService(slRef);

然后设置initial bundle start level：

1 // 设置新bundle的初始startlevel为系统配置项：org.osgi.framework.startlevel.beginning的值
2 Stringbsl = bundleContext.getProperty( " org.osgi.framework.startlevel.beginning " );
3 if (bsl != null && isInteger(bsl))sl.setInitialBundleStartLevel(Integer.parseInt(bsl));

这样所有新安装的bundle的初始化start level都将被设置为和系统配置项：org.osgi.framework.startlevel.beginning相同的值，以确保所有默认安装的 bundle都能启动。
修改osgi.properties中关于org.osgi.framework.startlevel.beginning的配置项，我改成了5：

1 #Specifiesthebeginningstartleveloftheframework.SeeStart
2 #LevelServiceSpecificationonpage 235 formoreinformation.
3 #
4 org.osgi.framework.startlevel.beginning = 5

增加一个方法，用于安装一个目录下所有的直属bundle，并且设置start level：

1 private static void installBundles(BundleContextbundleContext,FilebundleRoot,StartLevelsl, int bsl){
2 FilebundleFiles[] = bundleRoot.listFiles( new FilenameFilter(){
3 public boolean accept(Filedir,Stringname){
4 return name.endsWith( " .jar " );
5 }
6 });
7
8 if (bundleFiles != null && bundleFiles.length > 0 ){
9 for (FilebundleFile:bundleFiles){
10 try {
11 Bundlebundle = bundleContext.installBundle(bundleFile.toURL().toExternalForm());
12 if (sl != null && bsl > 0 )sl.setBundleStartLevel(bundle,bsl);
13 if (logger.isInfoEnabled())logger.info( " Installbundlesuccess: " + bundleFile.getName());
14 } catch (Throwablee){
15 if (logger.isWarnEnabled())logger.warn( " Installbundleerror: " + bundleFile,e);
16 }
17 }
18 }
19 }

最后，遍历start目录下的子目录来安装所有的bundle：

1 // 安装bundle并设置相应的startlevel
2 FileslRoot = new File(bundleRoot, " start " );
3 if (slRoot.isDirectory()){
4 FileslDirs[] = slRoot.listFiles( new FileFilter(){
5 public boolean accept(Filefile){
6 return file.isDirectory() && isInteger(file.getName());
7 }
8 });
9
10 for (FileslDir:slDirs){
11 installBundles(bundleContext,slDir,sl,Integer.parseInt(slDir.getName()));
12 }
13 }
14
15 // 安装直属目录下面的bundle
16 installBundles(bundleContext,bundleRoot,sl, 0 );

1 private static boolean isInteger(Stringvalue){
2 try {
3 Integer.parseInt(value);
4 return true ;
5 } catch (NumberFormatExceptione){
6 return false ;
7 }
8 }

最后，由于Declarative Services的存在，稍微调整了一下启动策略，所有包含Service-Component的header定义的bundle，也调用start方法来启动：

1 for (Bundlebundle:bundleContext.getBundles()){
2 if (bundle.getState() == Bundle.INSTALLED || bundle.getState() == Bundle.RESOLVED){
3 if (bundle.getHeaders().get(Constants.BUNDLE_ACTIVATOR) != null || bundle.getHeaders().get( " Service-Component " ) != null ){
4 try {
5 bundle.start(Bundle.START_ACTIVATION_POLICY);
6 if (logger.isInfoEnabled())logger.info( " Startbundle: " + bundle);
7 } catch (Throwablee){
8 if (logger.isWarnEnabled())logger.warn( " Startbundleerror: " + bundle,e);
9 }
10 }
11 }
12 }

clean Server然后启动Server，我们可以看到初始化后的bundle已经被赋予了指定Start Level。

附上initFramework方法的完整代码，更多的代码请参加以前的帖子：

" );
12
13 StringpluginLocation = servletContext.getInitParameter(CONTEXT_PARAM_OSGI_PLUGINS_LOCATION);
14 if (pluginLocation == null )pluginLocation = DEFAULT_OSGI_PLUGINS_LOCATION;
15 else if ( ! pluginLocation.startsWith( " / " ))pluginLocation = " / " .concat(pluginLocation);
16
17 // 安装bundle
18 FilebundleRoot = new File(servletContext.getRealPath(pluginLocation));
19 if (bundleRoot.isDirectory()){
20 if (logger.isInfoEnabled())logger.info( " LoadFrameworkbundlesfrom: " + pluginLocation);
21
22 // StartLevelService，用于设置bundle的 startlevel
23 ServiceReferenceslRef = bundleContext.getServiceReference(StartLevel. class .getName());
24 StartLevelsl = slRef == null ? null :(StartLevel)bundleContext.getService(slRef);
25 // 设置新bundle的初始startlevel为系统配置项：org.osgi.framework.startlevel.beginning的值
26 Stringbsl = bundleContext.getProperty( " org.osgi.framework.startlevel.beginning " );
27 if (bsl != null && isInteger(bsl))sl.setInitialBundleStartLevel(Integer.parseInt(bsl));
28
29 // 安装bundle并设置相应的startlevel
30 FileslRoot = new File(bundleRoot, " start " );
31 if (slRoot.isDirectory()){
32 FileslDirs[] = slRoot.listFiles( new FileFilter(){
33 public boolean accept(Filefile){
34 return file.isDirectory() && isInteger(file.getName());
35 }
36 });
37
38 for (FileslDir:slDirs){
39 installBundles(bundleContext,slDir,sl,Integer.parseInt(slDir.getName()));
40 }
41 }
42
43 // 安装直属目录下面的bundle
44 installBundles(bundleContext,bundleRoot,sl, 0 );
45
46 for (Bundlebundle:bundleContext.getBundles()){
47 if (bundle.getState() == Bundle.INSTALLED || bundle.getState() == Bundle.RESOLVED){
48 if (bundle.getHeaders().get(Constants.BUNDLE_ACTIVATOR) != null || bundle.getHeaders().get( " Service-Component " ) != null ){
49 try {
50 bundle.start(Bundle.START_ACTIVATION_POLICY);
51 if (logger.isInfoEnabled())logger.info( " Startbundle: " + bundle);
52 } catch (Throwablee){
53 if (logger.isWarnEnabled())logger.warn( " Startbundleerror: " + bundle,e);
54 }
55 }
56 }
57 }
58
59 if (slRef != null )bundleContext.ungetService(slRef);
60 }
61
62 new FileWriter(file).close();
63 if (logger.isInfoEnabled())logger.info( " Frameworkinited. " );
64 }
65 }

使用Tomcat原生API来动态管理 Web元素：原理

Tomcat的org.apache.catalina.Context接口提供了动态管理注入到Catalina Web Container中的Web元素的API。在基于OSGi的Web Application中，可以利用这个接口来实现在OSGi容器中动态管理Web元素的目的。为了达到这个目的，我们还需要做一些额外的配置。请注意，以下方法仅适用于Tomcat，并非通用的实现，而且只针对5.5.28版和6.0.24版的Tomcat做过简单的测试。

首先我们要做的事情，就是将Tomcat的org.apache.catalina.Context实现类作为Service注入到OSGi容器中去。在 OSGi-Web工程的WebContent/META-INF目录中，增加一个context.xml文件，内容如下：

这样我们就可以使用org.apache.catalina.ContainerServlet这个接口类了，通过它可以访问Catalina的内部功能，它有Catalina被类加载器加载，而不是我们的WebApplication类加载器。它的 Setter方法在这个Servlet的新的实例被放进Service时被执行。
接下来我们写一个Servlet，这个Servlet将实现ContainerServlet接口，请注意它是怎么工作的：

1 package org.dbstar.osgi.web.launcher.tomcat;
2
3 import java.util.Properties;
4
5 import javax.servlet.ServletException;
6 import javax.servlet.UnavailableException;
7 import javax.servlet.http.HttpServlet;
8
9 import org.apache.catalina.ContainerServlet;
10 import org.apache.catalina.Context;
11 import org.apache.catalina.Wrapper;
12 import org.dbstar.osgi.web.launcher.FrameworkConfigListener;
13 import org.osgi.framework.BundleContext;
14 import org.osgi.framework.ServiceRegistration;
15 import org.osgi.framework.launch.Framework;
16
17 public final class TomcatContextServlet extends HttpServlet implements ContainerServlet{
18 private static final long serialVersionUID = - 3977062987005392657L ;
19
20 private Wrapperwrapper;
21 private Contextcontext;
22
23 private ServiceRegistrationregistration;
24
25 public WrappergetWrapper(){
26 return wrapper;
27 }
28
29 public void setWrapper(Wrapperwrapper){
30 this .wrapper = wrapper;
31 if (wrapper == null )context = null ;
32 else context = (Context)wrapper.getParent();
33 }
34
35 @Override
36 public void init() throws ServletException{
37 // EnsurethatourContainerServletpropertieshavebeenset
38 if ((wrapper == null ) || (context == null )) throw new UnavailableException( " Wrappernotset. " );
39
40 // EnsurethatFrameworkhavebeenset
41 Frameworkframework = FrameworkConfigListener.getFramework();
42 if (framework == null ) throw new UnavailableException( " Frameworknotset. " );
43
44 // 将context注册为服务
45 registration = registerContext(framework.getBundleContext(),context);
46 }
47
48 private static ServiceRegistrationregisterContext(BundleContextbundleContext,Contextcontext){
49 Propertiesproperties = new Properties();
50 properties.setProperty( " DisplayName " ,context.getDisplayName());
51 properties.setProperty( " ContextPath " ,context.getPath());
52 return bundleContext.registerService(Context. class .getName(),context,properties);
53 }
54
55 @Override
56 public void destroy(){
57 if (registration == null ) return ;
58
59 Frameworkframework = FrameworkConfigListener.getFramework();
60 if (framework == null ) return ;
61
62 if (framework.getState() == Framework.ACTIVE)registration.unregister();
63 registration = null ;
64 }
65 }

通过ContainerServlet接口提供的setWrapper方法，我们获得了一个Wrapper实例，这个实例对应于 TomcatContextServlet部署到Tomcat中的封装类，通过其getParent方法我们就可以获得Servlet所在的 Context了。
接下来在init方法中，我们将获得的Context实例，通过Framework注册到OSGi容器中去。在destroy方法中，注销Context 的注册，这样形成了一个完整的生命周期。
然后，将这个TomcatContextServlet部署到web.xml中去：

1 
2 < servlet >
3 < servlet-name > TomcatContextServlet </ servlet-name >
4 < servlet-class > org.dbstar.osgi.web.launcher.tomcat.TomcatContextServlet </ servlet-class >
5 < load-on-startup > 1 </ load-on-startup >
6 </ servlet >

设置<load-on-startup>使这个Servlet在WebContainer初始化时加载，否则它将没有加载的机会，因为我们在应用中不会直接使用到这个Servlet。

最后还有一件事情不要忘记了，我们需要将org.apache.catalina及其相关的package export到OSGi容器中去，这样才能在OSGi容器中供给bundle来import。参照《打造一个基于OSGi的Web Application——为OSGi容器提供Web Application环境》一文中提到的方式，我们将catalina.jar作为extension Fragment的方式，引入到OSGi容器中去。
Catalina的MANIFEST.MF：

1 Manifest-Version: 1.0
2 Bundle-ManifestVersion: 2
3 Bundle-Name:CatalinaExtensionFragment
4 Bundle-SymbolicName:org.apache.catalina_extension ; singleton:=true
5 Bundle-Version: 5.5.28
6 Bundle-Vendor:dbstar
7 Fragment-Host:system.bundle ; extension:=framework
8 Bundle-RequiredExecutionEnvironment:J2SE- 1.5
9 Export-Package:org.apache.catalina , org.apache.catalina.authenticator ,
10 org.apache.catalina.connector , org.apache.catalina.core , org.apache.cat
11 alina.deploy , org.apache.catalina.loader , org.apache.catalina.mbeans , or
12 g.apache.catalina.realm , org.apache.catalina.security , org.apache.catal
13 ina.session , org.apache.catalina.startup , org.apache.catalina.users , org
14 .apache.catalina.util , org.apache.catalina.valves

在接下来的章节中，我会逐一描述如何在基于Tomcat的OSGi容器中，如何实现各种Web元素的动态管理，尽请期待哦：）

最后提供几个本章提到的bundle给大家下载，大家就不用自己再起生成一个了。
org.apache.catalina_extension_5.5.28.jar

分享到：

OSGi中获取Service的几种方式 | 世界最快的Java虚拟机JVM与内存泄露诊断

2010-06-12 09:51
浏览 1159
评论(0)
分类:开源软件
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

打造一个基于OSGi的Web Application

动机和目标

搭建开发环境

在WebApplication中启动 OSGi

为OSGi容器提供Web Application环境

在OSGi容器中管理Web元素的实现思路

增加日志输出功能

设置初始化bundle的 StartLevel

使用Tomcat原生API来动态管理 Web元素：原理

评论

发表评论

相关推荐

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

打造一个基于OSGi的Web Application

评论

发表评论

相关推荐

OSGi是什么：Java语言的动态模块系统

OSGi Bundle之Hello World

OSGi依赖性管理：Bundle访问域

OSGi服务：非常适合SOA的架构

OSGi和Spring入门：什么是Spring动态模型(Spring DM)？

OSGi与Spring：设置Spring DM开发环境

使用Spring DM创建Hello World，以及OSGi服务

使用OSGi构建面向服务的联络管理应用程序

OSGi与Spring DM：使用Spring DataSource

初探OSGi Web应用开发利器Equinox：环境设置

打造一个Hello World OSGi Web应用程序

部署并运行你的OSGi Web应用程序

OSGi中获取Service的几种方式

最近访客更多访客>>