精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-12-22
OpenCore: OSGi上部署Hibernate的四种方式 OpenCore是在OSGi规范上构建的微内核(Microkenerl),基于纯组件(Pure Plugin)开放源码企业应用软件平台。OpenCore数据层实现OSGi上集成Hibernate,Hibernate及其依赖库作为一个单独的插件,这样带来一个问题,就是OSGi平台的插件类加载机制使得Hibernate无法正确加载分布在不同插件内部的模型对象与O/R映射文件。本文讨论四种解决方案:
模型对象(Domain Objects)集中到独立的插件(Bundle)内,Hibernate插件依赖这些模型对象插件。这是最简单的,也是比较糟糕的方式,比较小的基于OSGi的项目可以这也作做。 依赖方式:业务插件------->Hibernate插件 | | | \ \| / |----------- 模型插件 /
把模型对象插件当作Hibernate插件的Fragments,依赖方式如图:
Equinox(Eclipse提供的OSGi实现)平台特有的方式,允许插件(Bundle)声明自己的伙伴,让“伙伴插件”来动态加载本插件的类,这也是Hiberate与Equinox集成的官方解决方案。这种方式模型对象无需部署在单独的插件内,与业务插件部署在一起即可,Hibernate插件也无须依赖模型对象。 具体做法如下: 首先,Hibernate插件(名称,例如org.opengoss.orm.hibernate)声明自身可以作为伙伴插件,自描述文件(MANIFEST.MF) 加入描述: Eclipse-BuddyPolicy: registered 然后,模型对象的业务插件中把Hibernate插件加入为伙伴,自描述文件(MANIFEST.MF) 加入描述: Eclipse-RegisterBuddy:org.opengoss.orm.hibernate 具体说明文档: http://www.hibernate.org/311.html http://www.ibm.com/developerworks/cn/opensource/os-ecl-osgi/index.html 注意:这种方式无法保证在Hibernate最新版本中应用成功。大家可以再试试:)
这是我们目前实现的方式,通过标准的Eclipse扩展点与扩展机制,我们在Hibernate插件中plugin.xml配置文件中声明下述扩展点: <plugin></plugin> <extension-point id="org.opengoss.database.domain.object" name="domainObject"/>
在模型对象插件中声明扩展,例如: <plugin></plugin> <extension></extension> <extension point="org.opengoss.database.domain.object"> <domainobject></domainobject> <domainObject class="org.opengoss.alarm.core.Alarm"/> </extension>
Hibernate插件的启动中,用代码配置生成SessionFactory,代码如下: public void start(BundleContext context) throws Exception { Configuration configuration = new Configuration().configure(new File( "./etc/org.opengoss.database.hibernate/hibernate.cfg.xml")); Class[] domainClasses = getDomainClasses(); for (Class domainClass : domainClasses) { configuration.addClass(domainClass); } sessionFactory = configuration.buildSessionFactory(); Dictionarynew Hashtable props.put("scope", "APPLICATION"); props.put("uid", "Hibernate:SessionFactory"); registration = context.registerService( SessionFactory.class.getName(), sessionFactory, props); } private Class[] getDomainClasses() throws Exception { List<class> domainClasses = </class>new ArrayList<class>();</class> IExtensionPoint point = registry .getExtensionPoint(IConstants.DOMAIN_OBJECT_EXTENSION_POINT); IExtension[] extensions = point.getExtensions(); for (IExtension extension : extensions) { IConfigurationElement[] elements = extension .getConfigurationElements(); for (IConfigurationElement configurationElement : elements) { Bundle bundle = pluginContext.getBundleBySymbolId(extension .getNamespaceIdentifier()); Class domainClass = bundle.loadClass(configurationElement .getAttribute("class")); domainClasses.add(domainClass); } } return domainClasses.toArray(new Class[domainClasses.size()]); } 注意:Hibernate内部的类加载机制实在无法令人满意,尽管我们在这种方式中已经加载所有的模型类对象,但Hibernate内部仍然会调用Class.forName()去试图加载。所以,我们不得不在其自描述文件(MANIFEST.MF) 中加入描述: DynamicImport-Package: * 结论:我们倾向于第四种方式,由Eclipse的扩展点功能来完成这一职责。不赞成第三种在OSGi规范层作改进的方式,OSGi本身的类加载机制设计非常优美,Buddy插件破坏了这种优美。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-12-23
呵呵,真的很不错的文章.
去年我们也尝试过把osgi推向服务端,后来因为各种原因放弃了. 同样也是因为OSGI的类加载机制,虽然如你所说,非常优雅,但是其扩展性还不够完美.毕竟Java中唯一能支撑大规模应用部署的东东就是classloader,几乎所有有意思的创新都是在它身上做文章,自然就对类加载机制有极高的可扩展性要求.因此我并不赞同您所说的"Buddy插件破坏了这种优美"的说法.这种需求是现实存在的,而且广泛存在. osgi为每个Bundle提供一个classloader的做法,在隔离运行时类的可见性上做得非常好,提高了类加载机制的动态性.然而这些classloader对类的载入过程很难去拦截,比如载入时和运行时织入方式的aop,这也是一个当前无法满足的需求 所以我对下一个版本的osgi规范充满期待:) 对于在osgi上部署hibernate,第四种方式或许是最好的,能在当前的通用机制下以常规的方式满足需求,自然很合适.这个没有异议. 顺便问一下,恕小子孤陋寡闻,请问OpenCore项目的具体信息和网站主页在哪里可以找到? |
|
返回顶楼 | |
发表时间:2006-12-25
open core 会在不久的将来开源出来。到时间通知大家。。
|
|
返回顶楼 | |
发表时间:2006-12-25
好东东!
|
|
返回顶楼 | |
发表时间:2006-12-25
不过OSGi是不是最近发展变慢了?
Oscar最新版本还是一年半前的. 但又看到好多项目都用OSGi. 能否多介绍些? |
|
返回顶楼 | |
浏览 9754 次