技术开发 频道

Java EE中的OSGi、JSR 294被叫停

  【IT168 评论】自从上次的bundle.update发布以来,在OSGi与模块化Java领域中发生了一系列值得我们关注的事件:JSR 294被叫停、Enterprise Expert Group发布了第4个草案、WebSphere上可以直接运行OSGi应用以及即将到来的OSGi大会对预先报名者提供折扣优惠,同时演讲人招募的时间即将截止。

  JSR 294被叫停

  Sun领导的两个模块化JSR(分别是JSR 294——Java语言改进的模块化支持,以及JSR 277——Java模块化系统)都已被叫停。这样就剩下JCP批准的模块化系统JSR 291(虽然基于有些古老的OSGi 4.1)仍活跃在各种系统中了,其中也包括Sun新近发布的GlassFish v3应用服务器。

  我们尚不清楚JSR 294为何会被叫停(JSR 277已经被叫停一年了)。小组收到的上一封邮件表明:

  • 除了实现JSR以外,JDK 7还将提供特定于实现的特性,比如classpath(没有任何一个JSR提过这部分内容)以及Jigsaw模块化系统。
  • JDK模块化使用了Jigsaw模块化系统。模块化的可见性是由一个原型化的模块info.java文件控制的,这在未来可能会发生变化。模块的私有访问实际上并没有在模块化中使用到,这部分主要是起引导作用的。
  • 关于Jigsaw的进一步讨论将在Jigsaw-dev列表中展开。

  简单模块系统自从被提出后就没有什么新进展,尽管版本的事情是由JSR 294控制的,但事实却并非如此,因为其开发过程是在jigsaw-dev邮件列表上进行的,而该邮件列表却游离于JSR 294专家组的邮件列表之外。种种事实表明Jigsaw采取了特定于实现的特性来模块化JDK,虽然这本身是非常好的,但却无法实现编写一次,到处运行的模块。可能以后这都不算什么大事了,因为JDK 7最早也要到2011年才会发布,应用服务器已经将宝压在了OSGi上了。

  更新:在本新闻发布后,Alex Buckley证实这种停止实际上是自动的,缘于提案发布的时间而不是说项目就停止开发了。

  WebSphere、GlassFish、DM Server以及基于OSGi的服务器

  Kirk Knoernschild发文表明一些企业正在构筑自己的OSGi,WebSphere V7 alpha最近就声明可以将OSGi bundle部署到WebSphere中(虽然从2006年开始WebSphere server就已经运行在OSGi内核上了)。

  最近发布的GlassFish v3也将OSGi运行时引入到了Sun的Java应用服务器中。尽管GlassFish还不支持直接运行本地的OSGi bundle,但我们可以将其置于Equinox和Felix上,可以在运行着的GlassFish服务器上同时运行其他bundle。

  SpringSource的dm Server 2.0.0.M6已经可以运行OSGi web bundle了,借助于其bundle仓库,dm Server指引着企业运行时的前进方向。

  Maven 3与Tycho构建、仓库以及Eclipse Marketplace

  随着Maven 3(其Tycho可以构建基于OSGi的应用)发布日期的临近,它将成为Eclipse构建EGit以及Tigerstripe的首选。

  相对于P2仓库来说,Maven仓库的查询能力受到了人们的质疑,但事实上,Maven仓库也可以进行查询。有事实可以证明,Maven仓库是整个Maven构建过程中最为成功的一个方面,它可以根据依赖关系自动下载所需的程序库。从Pack200压缩这个角度来看,P2可能更加高级一些,它还可以更新非JAR组件,然而Mave的über仓库在广度上轻而易举地就超越了Eclipse P2仓库。不仅如此,P2仓库经常被切分成多个独立的仓库,而Maven则具有一个所有项目都可共享的全局仓库。

  最近,Eclipse基金会发布了Eclipse Marketplace,它源自于成功的Eclipse插件中心2站点。最初建立EPIC的目的是提供一个中央下载站点,为那些不在Eclipse.org站点上的流行插件提供下载服务,比如Findbugs和Checkstyle。

  Eclipse基金会在2006年购买了EPIC的使用权,但后来就基本没再动过它,直到最近开发出了Eclipse Marketplace后这一点才有所改观。在这段时间内,由于缺乏统一的下载结构以及从Update Site到P2的转变极大地限制了中央下载站点(用于搜索及下载插件)的发展势头。

  除了插件以外,新的Marketplace还托管了RCP应用(既有商业的,也有免费的)以及培训与咨询供应商。

  最后要说的是IntelliJ 9的发布,其社区版与商业版都提供了对OSGi应用的支持。由于该优异Java IDE可以在本地构建OSGi应用,同时对OSGi应用又提供了巨大的支持,开发模块化Java应用变得空前的简单。

  OSGi 4.2 EEG草案发布

  最近Enterprise Expert Group发布了第4个草案。EEG的目的是定义一套规范以便JEE风格的应用可以作为本地bundle运行在OSGi运行时中。

  • 现在Web应用可以作为bundle使用了。这样不仅使得OSGi运行时能够托管WAR(与Jetty之类的服务器一样),同时WAR还可以在运行时中拥有版本依赖。Pax Web早就可以实现这一点了,但现在形成了标准,任何OSGi运行时都可以使用了。
  • OSGi框架中对bundle的JMX控制,对于核心OSGi服务的标准化绑定,比如Package Admin以及Cofniguration Admin等等。
  • 事务已经作为JTA绑定的一部分,这样就可以从OSGi服务中获取事务了。
  • JNDI访问既可以从OSGi中获取,也可以在OSGi服务间得到。
  • 兼容于OSGi的JDBC工厂(与Class.forName()不同)。

  凭借这些服务,企业应用可以运行在OSGi环境中而无需完整的JEE栈。尽管JEE 6已经发布,但它有可能是最后获得批准的几个JSR之一,Mark Reinhold如是说:

  Q:现在为何不开启一个closures JSR,让专家组完成提案工作?

  A:到目前为止Project Coin还没有一个JSR,原因与此类似,直到JCP执行委员会内部的争论平息之后才有可能提出新的Java SE JSR。

  即将到来的OSGi大会

  伦敦将于今年1月23日举办OSGi DevCon London,同时还将举办JAX London。现在,大会的议程已经确定下来了,Kirk Knoernschild将进行主题演讲。

  Santa Clara将于今年的3月22——25日举办OSGi DevCon,同时还有 EclipseCon 2010。Robert “Bob大叔” Martin将进行主题演讲。目前还在招募演讲者,如果你有这方面的想法,请递交你的提案。

  查看英文原文:Bundle.update: OSGi in Java EE, JSR 294 Marked Inactive

  译文

0
相关文章