Mais conteúdo relacionado 3. 大纲 OSGi介绍 OSGi实现框架 扩展Equinox Equinox高级实战 分布式OSGi 8. Bundle类隔离机制 Java ClassLoader机制 类由ClassLoader来实现加载，Java动态化实现的基础； 默认情况下有BootStrapClassLoader(jre/lib、jre/classes)、Extension ClassLoader(jre/lib/ext)以及System ClassLoader(-classpath指定)三个级别的ClassLoader； 应用可自行实现ClassLoader以动态的加载类，或加载相应目录下的类； 11. Bundle类共享机制 Bundle类加载过程 java.*委派给parent classloader加载； bootdelegation参数中配置的也委派给parent classloader加载，在parent classloader中未找到也继续下面的步骤； 是否在Import-Package中，在则委派给Export-Package的bundle的classloader； 是否在Require-Bundle中，在则委派给相应的Bundle ClassLoader，未找到则继续下面步骤； 在Bundle-Classpath中寻找，未找到则继续下面的步骤； 在fragments bundle的classpath中寻找，未找到则继续下面的步骤； 是否在Export-Package中，未找到则继续下面的步骤； 是否在DynamicImport-Package中，在则委派给相应的Bundle ClassLoader寻找，不在则抛出ClassNotFound异常。 16. Bundle生命周期 Resolve Bundle时要做的事情 寻找Bundle中所需依赖的包或Bundle是否存在以及被resolve，包括寻找匹配的import-package、require-bundle等，如寻找到则进入检查，检查完冲突后形成绑定关系，以便加载类时能直接加载； 冲突示例 A Bundle依赖org.osgiusers.china.demo;version=1.0.0,org.osgiusers.china.user;version=2.0.0; B Bundle提供了org.osgiusers.china.demo;version=1.0.0，但同时import了org.osgiusers.china.user;version=1.1.0 如成功，则将Bundle状态置为RESOLVED。 18. Bundle生命周期 Stop Bundle时要做的事情 卸载当前Bundle对外提供的所有OSGi Service，并释放当前Bundle引用的所有OSGi Service； 调用MANIFEST.MF中对应的Bundle-Activator的类的stop方法； 将Bundle状态置为RESOLVED。 19. Bundle生命周期 Uninstall Bundle时要做的事情 检查Bundle状态，如状态为ACTIVE，则先STOP； 释放Bundle对其他Bundle的类依赖； 如当前Bundle中有其他Bundle的类依赖，则进行记录，如没有则释放该Bundle的ClassLoader； 将当前Bundle的状态置为UNINSTALLED。 22. Bundle交互 Service registry packages packages 直接类访问的方式（不推荐），结合上面之前的Bundle生命周期的介绍，为什么？； Service交互方式 直接通过BundleContext.getServiceReference以及BundleContext.registerService这样的方式（使用不方便，不推荐）； Declarative Services方式，类似IoC type 2； OSGi Framework Bundle Bundle JAVA Operating System Hardware 23. Bundle交互 Declarative Services（简称DS） Service-Oriented Component Model 需要对外提供的功能均定义为接口； 接口的实现定义以XML方式定义为Component； 按接口的方式访问其他Bundle的功能； 以XML方式定义对其他Bundle的功能的访问； Component也是有生命周期的。 OSGi R4.0的重大改进就是这点！ 25. Bundle交互 提供服务关键配置 provide interface，声明对外提供的接口； property，可增加一些服务实现的关键词，以便匹配过滤，例如<property name=“KEY” value=“DB”/> 调用服务关键配置 cardinality 配置调用服务的数量，例如0..1、1..n、0..n； policy 配置引用的服务变化时的策略，主要有static和dynamic这两种； target 配置引用的服务的过滤，例如target=“(KEY=DB)”，这样即使有多个提供了接口的服务，也只会注入配置了KEY=DB的这个； 26. Bundle交互 DS 1.1的可喜变化 Service-Component后指定的文件可用通配符，例如：Service-Component: OSGi-INF/*.xml 可以配置activate和deactivate方法，并且提供了多种方法签名的支持； bind、unbind方法加了两种签名的支持； void <method-name>(ServiceReference) void <method-name>(<parameter-type>,Map) 增加的这个方法签名至关重要，尤其是对于按服务属性来选择服务的场景而言。 28. Bundle交互 Component生命周期 当有Bundle启动时，会触发Declarative services的介入，以将其中的Service-Component对应的配置文件的Component载入； 当有Bundle通过BundleContext直接注册服务时，也将触发Declarative Services，以检查是否有Component可被激活； 当有Bundle STOP时，也会触发DS的介入，以将相关的OSGi Service卸载和释放，并检查相关的Component是否要被销毁； 如何做到引用的服务更新了，但当前Component并不会重新创建实例？ 29. R 4.2将会带来的变化 Launch Framework API 这个API的引入就意味着以后可以以一种统一的方式在程序中启动OSGi Framework了，示例如下： Map p=new HashMap(); p.put(“org.osgi.framework.storage”,System.getProperties(“user.home”)+File.separator+”osgi”); FrameworkFactory factory=Class.forName(factoryClassName).newInstance(); Framework framework=factory.newFramework(p); framework.init(); BundleContext context=framework.getBundleContext(); …//安装Bundles framework.start(); framework.waitForStop(); 30. OSGi提供的服务 Http Service 以便支持简单的通过http访问OSGi应用； 但复杂的场景还是比较难支撑，这主要是由于目前还只有jetty实现的HttpService，再加上它所支持的Servlet版本太低，这也导致了目前OSGi对于Web类型的应用而言支持不足，但可喜的是RFC 66会带来很多变化； Log Service 支持简单的日志记录，直接输出到console，不过可以结合log4j自行实现； EventAdmin Service 基于此可实现事件通知性质的功能； ConfigurationAdmin Service 基于此可实现配置信息的动态管理。 31. OSGi对模块化、动态化的满足程度 模块化 完全满足。 动态化 能够动态的增加、删除或更新模块，并完成依赖的OSGi Service的引用迁移； 但要自行处理由此带来的模块中对象的状态保持和恢复的问题，因此基于OSGi了，并不就代表应用一定可动态了，要合理的基于Bundle生命周期改变和Component生命周期改变会带来的变化做相应的处理。 33. OSGi实现框架 Equinox Equinox是R 4.0的RI，并且也是Eclipse的核心，可谓是久经考验，Spring-DM也是基于Equinox。 Felix Felix作为后起之秀，表现算得上是非常突出了。 其他 Oscar、Knoperfish已是昨日黄花了； 35. OSGi实现框架 Equinox中的类加载顺序 根据启动时的bootdelegation属性判断是否需要从parent classloader中加载，具体parent classloader是哪个，则可以通过osgi.parentClassLoader属性来指定，支持的为：app（SystemClassLoader）、ext（Extension ClassLoader）和fwk（Equinox ClassLoader）三种； 调用Equinox的ClassLoaderDelegateHook的preFindClass来加载； 从Import-Package中寻找； 从Require-Bundle中寻找； 尝试从当前Bundle中加载； 尝试从DynamicImport-Package中加载； 调用Equinox的ClassLoaderDelegateHook的postFindClass来加载； 尝试使用Eclipse的buddy机制来加载； 对比规范而言，Equinox除了增加了Hook机制以及buddy机制外，完全遵守OSGi规范。 36. OSGi实现框架 Equinox Install Bundle 按照提供的Bundle文件加载流，并根据MANIFEST.MF的信息形成Bundle对象，并将Bundle的状态置为INSTALLED； 对外广播Bundle INSTALLED事件。 37. OSGi实现框架 Equinox Resolve Bundle 如bundle为singleton，则首先检查singletons bundle是否已存在，如存在则resolve失败； 对所依赖的package进行寻找、检查和绑定； 寻找require-bundle、import-package匹配的bundle； 检查这些bundle之间是否有冲突，尽可能的选择没有冲突的bundle； 绑定通过检查的bundle，以便在加载类时可直接去这些bundle中寻找。 将Bundle状态设置为RESOLVED。 38. OSGi实现框架 Equinox Start Bundle 检查状态是否为RESOLVED，如未resolve则先进行resolve动作，resolve失败则直接抛出异常，成功则继续下面步骤； 调用MANIFEST.MF中配置的bundle-activator对应的类的start方法。 将Bundle状态置为ACTIVE。 39. OSGi实现框架 Equinox Stop Bundle 注销发布的OSGi服务以及释放对其他OSGi服务的引用； 调用MANIFEST.MF中配置的bundle-activator的类的stop方法； 将Bundle状态置为RESOLVED。 40. OSGi实现框架 Equinox Uninstall Bundle 如Bundle为Active，先停止Bundle； 检查是否有其他Bundle依赖了当前Bundle的package，如有则先不关闭此bundle的classloader，如没有则关闭； 将Bundle状态置为UNINSTALLED。 41. OSGi实现框架 Equinox Update Bundle 如状态为ACTIVE，先停止； 创建新的Bundle对象，如有Bundle依赖老版本的Bundle，则暂时将老版本的Bundle放入removalPendings中，如没有，则清除老版本Bundle的所有信息； 恢复新版本的Bundle到更新前的状态。 43. OSGi实现框架 Equinox DS在这些过程中的处理 Start Bundle时 扫描MANIFEST.MF中对应的Service-Component指定的文件，加载这些文件； 判断其中指定的Component是否符合激活条件，如符合，则激活并调用activate方法，对于提供了OSGi Service的Component，则注册此OSGi Service； Stop Bundle时 不做任何动作； 有服务注册时 寻找当前的Component是否有可激活的，如有则进行激活； 寻找当前已激活的Component中是否有需要此OSGi Service的，如有则调用其bind-method进行注入； 有服务注销时 对于依赖了此OSGi Service的component，调用其unbind-method； 检查是否有Component因此不到激活条件的，则尝试调用Component的deactivate方法并销毁Component的实例。 46. OSGi实现框架 Felix Install Bundle 解析Bundle的MANIFEST.MF文件，读取OSGi标准中定义的头信息； 检查Bundle的唯一性，如不唯一则抛出异常； 将Bundle状态置为INSTALLED。 47. OSGi实现框架 Felix Resolve Bundle 寻找需要依赖的Package或Bundle，并将其中未resolve的Bundle进行resolve，如resolve失败，则将其从潜在的Bundle列表中删除，这步完全遵循OSGi规范； 检查是否有符合条件的Bundle，如没有，则抛出异常，有则继续； 检查这些符合条件的潜在的Bundle，如多个同名称的单态Bundle、版本冲突等问题，如这些问题均不存在，则继续下面的步骤； 完成绑定。 48. OSGi实现框架 Felix Start Bundle 检查Bundle状态，如未resolve则先resolve； 执行MANIFEST.MF中对应的Bundle-Activator配置的类的start方法，如未配置则跳过此步； 将Bundle状态设置为ACTIVE； 49. OSGi实现框架 Felix Stop Bundle 执行MANIFEST.MF中对应的Bundle-Activator配置的类的stop方法，如未配置则跳过此步； 注销Bundle对外发布的Service； 释放Bundle引用的Service； 50. OSGi实现框架 Felix Uninstall Bundle 检查状态，如为ACTIVE，则先停止； 如有其他Bundle引用了当前Bundle的package，则将当前Bundle的RemovalPending设置为true； 将Bundle状态设置为UNINSTALLED； 如未被其他Bundle使用，则对当前Bundle执行refresh动作； 52. OSGi实现框架 Felix Refresh 在指定Bundle的情况下，递归找到依赖当前Bundle提供的package的Bundle，作为此次refresh动作需要操作的Bundles；在未指定Bundle的情况下，则将已卸载的且RemovalPending为true的Bundles，以及还未resolve的Bundle作为此次需要操作的Bundles； refresh负责将需要uninstall的Bundle对外export的package彻底关闭，并对需要依赖这些package的bundle执行STOP动作； 对于不需要Uninstall但在refresh动作范畴的bundles恢复为之前的状态。 53. OSGi实现框架 Felix DS在这些过程中的处理 和Equinox基本一致； 但值得注意的是Felix DS 1.0.8对于policy=dynamic、cardinality=“0..1” | “0..n”这类依赖服务变更时的处理有个bug，会造成在依赖的服务更新后出现需要此服务的Component拿不到服务引用的现象。 56. 扩展Equinox 在外部程序中启动Equinox 示例 // 配置Equinox的启动 FrameworkProperties.setProperty("osgi.noShutdown", "true"); FrameworkProperties.setProperty("eclipse.ignoreApp", "true"); FrameworkProperties.setProperty("osgi.bundles.defaultStartLevel", "4"); FrameworkProperties.setProperty("osgi.bundles", "// 指定需要装载的Bundle的路径"); // 指定需要加载的bundles所在的目录 FrameworkProperties.setProperty("osgi.syspath", "// 例如plugins"); EclipseStarter.run(new String[]{"-configuration","configuration","-console"}, null); // 通过EclipeStarter获取到BundleContext context=EclipseStarter.getSystemBundleContext(); 到了R 4.2后就可以遵循标准的API来启动了 61. 扩展Equinox 注册Hook类的方法 属性中指定 在启动时指定osgi.hook.configurators，但要注意的是要加上目前Equinox所需的hooks配置，格式为： hook.configurators=hook类名,hook类名 此文件需要放在Equinox框架的classpath下； 配置文件中指定 增加一个hookconfigurators.properties，其中的格式为： hook.configurators=hook类名,hook类名 65. Equinox高级实战 将非DS的应用迁移为DS方式 迁移的方法 将之前直接类的调用方式改为基于接口的方式，这也将对动态化的实现更为有利； 将接口放入一个独立的Bundle中，也是为了动态化； 将注册服务的代码去掉，改为通过编写xml文件来注册服务； 将调用服务时依赖BundleContext获取的方式去掉，改为set注入的方式，并通过unset来感知服务的注销； 编写XML文件来定义需要调用的OSGi Service； 最后就是在运行的Bundle中增加DS实现的Bundle。 67. Equinox高级实战 将非DS的应用迁移为DS方式 DS的四种经典用法 set注入单个依赖的服务； <reference name=… interface=… bind=… unbind=… policy=…/> set注入单个指定标识的依赖的服务； <reference name=… interface=… bind=… unbind=… policy=… target=“(key=DB)”/> set注入多个依赖的服务，在调用时进行全调用，类似filter chain或hook； <reference name=… interface=… bind=… unbind=… policy=… cardinality=“0..n”/> set注入多个依赖的服务，调用时根据某标识来调用其中的一个服务，实现类似的Factory机制； <reference name=… interface=… bind=… unbind=… policy=… cardinality=“0..n”/> set方法签名则改为void <method-name>(interface,Map) （必须是DS 1.1+） 从上面四种用法来看，DS甚至强于了现在所有的IoC容器。 68. Equinox高级实战 经常会碰到的一些问题 ClassNotFoundException 几乎是所有使用OSGi的人都会经常碰到的问题； 解决的方法是掌握Bundle Class的加载方式； ClassCastException 几乎是所有使用OSGi的人都会经常碰到的问题； 解决的方法是掌握ClassLoader的基本原理以及Bundle Class的加载方式； OSGi Component没启动 这是比较麻烦的问题； 解决的方法首先是掌握OSGi Component的激活条件； 然后是通过OSGi Console，查看log，或仔细检查Component .xml的配置； 70. 分布式OSGi 你所期望的？ 我所期望的 透明的将OSGi服务发布为可远程调用的服务； 透明的调用远程的OSGi服务； OSGi服务的动态化感知不是必须的 由于这受限于网络等各种因素，而且如果服务有多级调用的话就会出现类似的雪崩效应； 73. 分布式OSGi R-OSGi 能达到的效果 透明的将OSGi Service对外发布； 只需要在注册OSGi Service时加上properties.put(RemoteOSGiService.R_OSGi_REGISTRATION, Boolean.TRUE); 属性 透明的调用远程的OSGi Service； 只需获取RemoteOSGiService，然后就可以调用远程的OSGi Service； 由于调用时基于的是TCP/IP，例如其提供了基于mina的调用，因此性能还是不错的； 可基于jSLP实现Service Discovery，从而更加简单的找到需要调用的远程OSGi Service。 74. 分布式OSGi R-OSGi 实现机制 监听了服务注册事件，当有服务注册时，检查其注册的属性，如属性中有RemoteOSGiService.R_OSGi_REGISTRATION，并且值为true，那么则做一个服务接口名与此服务的映射，并将此映射作为tcp/ip某端口的处理器集合。 对于客户端，当通过RemoteOSGiService拿到引用时，为一个服务端调用的代理，当调用此引用的方法时，即代理访问到远端服务器，过程即为一个类似的自定义的java远程RPC。 75. 分布式OSGi CXF DOSGi 能达到的效果 透明的将OSGi Service对外发布； 只需在注册服务时增加如下属性即可： props.put("osgi.remote.interfaces", "*"); props.put("osgi.remote.configuration.type", "pojo"); props.put("osgi.remote.configuration.pojo.address", WebService URL); 透明的调用远程OSGi Service 增加一个remote-services.xml，按照格式描述所需调用的远程OSGi Service； 调用时直接以接口的方式调用远程OSGi Service即可，完全透明； 从这点对比而言，CXF DOSGi要强于R-OSGi，毕竟R-OSGi的完全透明还是需要做点包装的。 76. 分布式OSGi CXF DOSGi 实现机制 监听服务注册事件，当注册时有相应的属性时，则将其发布为Webservice； 对于客户端，则通过扫描相应的service-description的描述来生成一个调用远程Webservice的代理，并将此代理注册为相应的OSGi Service。
