接下来的图片试图给出关于GlassFish运行在OSGI平台上运行机制是怎样的：
所有的GlassFish包含JavaEE APIs模快被打包成OSGI绑定。你们中一些人也许想知道什么HK2角色。HK2有下列层：
模块层-负责类加载和生命周期管理。
组件层-负责组件的注册，注入，等等
配置层-负责从XML文件中读取数据配置组件。XML文件可以被更新去发射组件中的改变。
一个简单的类图-展示了部分HK2的精华(除了配置层)-展示如下：
我们已经通过代理给OSGI模块层在OSGi上实现了HK2'模块。HK2的组件层和配置层依赖HK2模块的APIs.一旦这些API可以使用，这两个层在OSGI绑定上使用不再是个问题。除了一些情况比如URLStreamHandler注册，GlassFish模块不直接使用OSGi的API;他们使用HK2模块API(可以在两种运行机制下使用)。这使得他们可以在没有改变的情况下运行在两种运行机制下。改天，我讨论service mapper.
最后，我要去感谢Felix社区对这个论坛的完美的支持。不仅是引文这个框架我用起来很方便，而且他们的maven-bundle-plugin插件-打包了Peter Krien's bnd工具-使得maven用户使用更容易。
现在，在我你问我之前，我抢先说点：
为什么我们采用该方法：
许多GlassFish 代码已经写好，所以我们要一个更容易的，不破坏我们的日程计划的迁移方案。
这种方法有什么好处？
可以让你经历两种模式，理论上，我们可以它相对轻松转换到给定的另外一个兼容的模块系统。
这种方法有什么却掉？
限制我们使用HK2 API,我们不能利用OSGi提供的富模块管理的好处。
我们继续支持这两个模块吗？
不会支持太长的时间。但是，不意味着HK2将消失。像Jerme在他的Blog中解释的那样，HK2将继续提供组件和平配置层。
GlassFish怎么使用绑定库？
我们下一步将研究这个。
其他什么OSGi实现运行？
理论上讲，既然我们代码按照R4说明写，因该可以运行在任何兼容的实现上-我将说的是配置的事情。我们已经尝试了三个主要的，成功了。还有更多去这样做。Felix想在是我们的默认平台-被发布成我们运行机制的一部分。
下一步是什么？
现在仅仅是个开始。我们还有很多事情排队等着被做。我有一个很长的做过优先级TODO的清单。我们希望你能提供建设性的反馈，使他变得更好。像Eduardo在他的Blog中提及的那样，请等待我们稳定的buils.
//原文见 http://weblogs.java.net/blog/ss141213/archive/2008/04/glassfish_v3_on.html
- 查看图片附件