诺夫勒鱼包装

发布于 2024-08-27 23:41:34 字数 1345 浏览 6 评论 0原文

我目前正在创建一个矩阵,显示 Knopflerfish、Equinox 和 Felix 在多大程度上符合 OSGi 4.2。

到目前为止,我查看了 Knopflerfish 文档(链接 1链接 2)了解实际实现了多少核心和纲要规范。

尽管关于安全层和声明性服务存在一些不一致的说法,但核心规范似乎已完全实现。

让我想知道有多少 Compendium 规范得到了实现:

  • 远程服务
  • 日志服务
  • Http 服务
  • 设备访问
  • 配置管理服务
  • 元类型服务
  • 首选项服务
  • 用户管理服务
  • 线路管理服务
  • IO 连接器服务
  • 初始配置
  • UPnP 设备服务
  • 声明性服务
  • 事件管理服务
  • 部署管理
  • 自动配置
  • 应用程序管理
  • DMT 管理服务
  • 监控 管理服务
  • 外部应用程序访问
  • 蓝图容器
  • 跟踪
  • 器 XML 解析器 服务
  • 位置
  • 测量和状态
  • 执行环境

要了解更多信息,我下载了 (下载页面) Knopflerfish的源代码并查看了它。看起来规范的某些部分是通过 OSGi 联盟 (org.osgi.*) 提供的“原始”框架实现的。

UPnP 包就是一个示例:

alt text http://img6.imageshack.us/img6 /5853/screenshot20100403at212.png

这是否意味着通过“原始”OSGi 框架添加了 Knopflerfish 未直接实现的缺失部分?

这是否也适用于其他像 Felix 或 Equinox 这样的框架?

I am at the moment creating a matrix which is showing how far Knopflerfish, Equinox and Felix are OSGi 4.2 compliant.

So far I looked at the Knopflerfish documentation (Link 1, Link 2) to get an idea of how much of the Core and Compendium specs are actually implemented.

The core specification seems to be fully implemented, although there are some inconsistent statements about the Security Layer and the Declarative Services.

What makes me wonder is how much of all the Compendium specs are implemented:

  • Remote Services
  • Log Service
  • Http Service
  • Device Access
  • Configuration Admin Service
  • Metatype Service
  • Preferences Service
  • User Admin Service
  • Wire Admin Service
  • IO Connector Service
  • Initial Provisioning
  • UPnP Device Service
  • Declarative Services
  • Event Admin Service
  • Deployment Admin
  • Auto Configuration
  • Application Admin
  • DMT Admin Service
  • Monitor Admin Service
  • Foreign Application Access
  • Blueprint Container
  • Tracker
  • XML Parser Service
  • Position
  • Measurement and State
  • Execution Environment

To find out more I downloaded (Download page) the source code of Knopflerfish and had a look at it. It looks like some parts of the spec are implemented through the "original" framework provided by the OSGi Alliance (org.osgi.*).

One example is the UPnP package:

alt text http://img6.imageshack.us/img6/5853/screenshot20100403at212.png

Does this mean that missing parts which are not directly implemented by Knopflerfish are added through the "original" OSGi framework?

And does this also apply to other frameworks like Felix or Equinox?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

她说她爱他 2024-09-03 23:41:34

大多数 OSGi 规范都定义了服务的接口类。您可以直接从 OSGi 联盟的网站下载这些类以及规范。

诸如 Knopflerfish 之类的实现必须提供底层功能,例如您在示例中提到的 UPnP 服务管理的实际实现。一些接口类还提供必须由用户服务的开发者实现的接口,例如BundleActivator。

所有声称兼容 OSGi 的框架都必须提供这些接口的实现。不存在“原始”OSGi 框架(当然,除了参考实现之外)。接口不提供实现。

Most of the OSGi specifications define interface classes for services. You can download these classes together with the specification directly from the OSGi Alliance's website.

Implementations such as Knopflerfish must provide the underlying functionalities, e.g. the actual implementation for the UPnP Service Admin you mentioned in your example. Some of the interface classes also provide interfaces that must be implemented by the developer of a user service, e.g. a BundleActivator.

All frameworks that claim to be OSGi compliant must provide implementations for these interfaces. There is no "original" OSGi framework (well, beside of the reference implementation, of course). The interfaces do not provide implementations.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文