java 开始使用 OSGI 的最佳方式是什么？

What's the best way to get started with OSGI?

提问by Nicholas Trandem

What makes a module/service/bit of application functionality a particularly good candidate for an OSGi module?

是什么让一个模块/服务/位应用程序功能成为 OSGi 模块的一个特别好的候选？

I'm interested in using OSGiin my applications. We're a Java shop and we use Spring pretty extensively, so I'm leaning toward using Spring Dynamic Modules for OSGi(tm) Service Platforms. I'm looking for a good way to incorporate a little bit of OSGi into an application as a trial. Has anyone here used this or a similar OSGi technology? Are there any pitfalls?

我有兴趣在我的应用程序中使用OSGi。我们是一家 Java 商店，我们非常广泛地使用 Spring，所以我倾向于使用Spring Dynamic Modules for OSGi(tm) Service Platforms。我正在寻找一种将一点 OSGi 结合到应用程序中作为试用的好方法。这里有没有人使用过这个或类似的 OSGi 技术？有什么陷阱吗？

@Nicolas - Thanks, I've seen that one. It's a good tutorial, but I'm looking more for ideas on how to do my first "real" OSGi bundle, as opposed to a Hello World example.

@Nicolas - 谢谢，我看过那个。这是一个很好的教程，但我正在寻找更多关于如何做我的第一个“真正的”OSGi 包的想法，而不是一个 Hello World 示例。

@david - Thanks for the link! Ideally, with a greenfield app, I'd design the whole thing to be dynamic. What I'm looking for right now, though, is to introduce it in a small piece of an existing application. Assuming I can pick any piece of the app, what are some factors to consider that would make that piece better or worse as an OSGi guinea pig?

@david - 感谢您的链接！理想情况下，使用全新的应用程序，我会将整个事物设计为动态的。不过，我现在正在寻找的是在现有应用程序的一小部分中引入它。假设我可以选择应用程序的任何部分，有哪些因素可以使该部分作为 OSGi 豚鼠变得更好或更坏？

采纳答案by Boris Terzic

Well, since you can not have one part OSGi and one part non-OSGi you'll need to make your entire app OSGi. In its simplest form you make a single OSGi bundle out of your entire application. Clearly this is not a best practice but it can be useful to get a feel for deploying a bundle in an OSGi container (Equinox, Felix, Knoplerfish, etc).

好吧，由于您不能拥有一部分 OSGi 和一部分非 OSGi，因此您需要制作整个应用程序 OSGi。以最简单的形式，您可以从整个应用程序中创建一个单一的 OSGi 包。显然，这不是最佳实践，但它有助于了解在 OSGi 容器（Equinox、Felix、Knoplerfish 等）中部署包。

To take it to the next level you'll want to start splitting your app into components, components should typically have a set of responsibilities that can be isolated from the rest of your application through a set of interfaces and class dependencies. Identifying these purely by hand can range from rather straightforward for a well designed highly cohesive but loosely coupled application to a nightmare for interlocked source code that you are not familiar with.

为了更上一层楼，您需要开始将您的应用程序拆分为组件，组件通常应具有一组职责，这些职责可以通过一组接口和类依赖项与应用程序的其余部分隔离。纯手工识别这些范围可以从设计良好的高内聚但松散耦合的应用程序的相当简单到您不熟悉的互锁源代码的噩梦。

Some help can come from tools like JDependwhich can show you the coupling of Java packages against other packages/classes in your system. A package with low efferent coupling should be easier to extract into an OSGi bundle than one with high efferent coupling. Even more architectural insight can be had with pro tools like Structure 101.

一些帮助可以来自像JDepend这样的工具，它可以向您展示 Java 包与系统中其他包/类的耦合。具有低传出耦合的包应该比具有高传出耦合的包更容易提取到 OSGi 包中。使用Structure 101等专业工具可以获得更多的架构洞察力。

Purely on a technical level, working daily with an application that consists of 160 OSGi bundles and using Spring DM I can confirm that the transition from "normal" Spring to Spring DM is largely pain free. The extra namespace and the fact that you can (and should) isolate your OSGi specific Spring configuration in separate files makes it even easier to have both with and without OSGi deployment scenarios.

纯粹在技术层面上，每天使用由 160 个 OSGi 包组成的应用程序并使用 Spring DM，我可以确认从“正常”Spring 到 Spring DM 的转换在很大程度上是无痛的。额外的命名空间以及您可以（并且应该）在单独的文件中隔离 OSGi 特定的 Spring 配置这一事实，使得无论有没有 OSGi 部署场景都更加容易。

OSGi is a deep and wide component model, documentation I recommend:

OSGi 是一个深而广的组件模型，我推荐的文档：

• OSGi R4 Specification: Get the PDFs of the Core and Compendium specification, they are canonical, authoritative and very readable. Have a shortcut to them handy at all times, you will consult them.
• Read up on OSGi best practices, there is a large set of things you cando but a somewhat smaller set of things you shoulddo and there are some things you should never do(DynamicImport: * for example).

• OSGi R4 规范：获取 Core 和 Compendium 规范的 PDF，它们是规范的、权威的并且非常易读。在任何时候都有一个方便的快捷方式，你会咨询他们。
• 阅读 OSGi 最佳实践，你可以做很多事情，但你应该做的事情少一些，还有一些你永远不应该做的事情（例如 DynamicImport: *）。

Some links:

一些链接：

• OSGi best practices and using Apache Felix
• Peter Kriens and BJ Hargrave in a Sun presentation on OSGi best practices
• one key OSGi concept are Services, learn why and how they supplant the Listener pattern with the Whiteboard pattern
• The Spring DM Google Groupis very responsive and friendly in my experience
  The Spring DM Google Groupis no longer activeand has moved to Eclipse.org as the Gemini Blueprint project which has a forum here.

• OSGi 最佳实践和使用 Apache Felix
• Peter Kriens 和 BJ Hargrave 在关于 OSGi 最佳实践的 Sun 演讲中
• 一个关键的 OSGi 概念是服务，了解为什么以及如何用白板模式取代侦听器模式
• 春天DM谷歌集团是在我的经验非常敏感和友好
  的春天DM谷歌集团是不再有效，并已移到Eclipse.org作为具有论坛双子座蓝图项目在这里。

回答by Toni Menzel

When learning a new technology rich tooling gets you into things without big headaches. At this point the community at ops4j.orgprovides a rich toolset called "PAX" which includes:

学习新技术时，丰富的工具可以让您轻松进入事物。此时，ops4j.org上的社区提供了一个名为“PAX”的丰富工具集，其中包括：

• Pax Runner: Run and switch between Felix, Equinox, Knopflerfish and Concierge easily
• Pax Construct: Construct, Organize & Build OSGi projects with maven easily
• Pax Drone: Test your OSGi bundles with Junit while being framework independent (uses PaxRunner)

• Pax Runner：在 Felix、Equinox、Knopflerfish 和 Concierge 之间轻松运行和切换
• Pax Construct：使用 maven 轻松构建、组织和构建 OSGi 项目
• Pax Drone：在独立于框架的同时使用 Junit 测试您的 OSGi 包（使用 PaxRunner）

Then there are many implementations of OSGi compendium services:

然后有很多 OSGi 纲要服务的实现：

• Pax Logging(logging),
• Pax Web(http service),
• Pax Web Extender(war support),
• Pax Coin(configuration),
• Pax Shell(shell implementation, part of the next osgi release)
• and much more.

• Pax Logging（记录），
• Pax Web（http 服务），
• Pax Web Extender（War支持），
• Pax Coin（配置），
• Pax Shell（shell 实现，下一个 osgi 版本的一部分）
• 以及更多。

.. and there is a helpful, framework independend community, - but thats now advertisement ;-)

.. 并且有一个有用的、框架独立的社区，-但那现在是广告;-)

回答by Jér?me Verstrynge

This answer comes nearly 3 years after the question was asked, but the linkI just found is really good, especially for starters using maven. A step-by-step explanation.

这个答案是在提出这个问题将近 3 年后才出现的，但我刚刚找到的链接非常好，尤其是对于使用 maven 的初学者。一步一步的解释。

回答by Wazza

Try http://njbartlett.name/files/osgibook_preview_20091217.pdf

试试http://njbartlett.name/files/osgibook_preview_20091217.pdf

OR

或者

http://www.manning.com/hall/

http://www.manning.com/hall/

The second is not a book i have read myself but I have heard good things about it.

第二本书不是我自己读过的书，但我听说过关于它的好消息。

The first was very useful for me. He takes you through the architecture initially and then it's hands on OSGi.

第一个对我很有用。他首先带您了解架构，然后动手操作 OSGi。

回答by Kamlesh

Try http://neilbartlett.name/blog/osgibook/. The book has hands on examples with OSGi best practices.

试试http://neilbartlett.name/blog/osgibook/。这本书有 OSGi 最佳实践的实例。

回答by Steven Dick

Is your existing application monolithic or tiered in seperate processes/layers?

您现有的应用程序是整体式的还是分层的？

If tiered, you can convert the middle/app-tier to run in an OSGi container.

如果分层，您可以将中间/应用层转换为在 OSGi 容器中运行。

In my team's experience, we've found trying to do web-stuff in OSGi painful. Other pain points are Hibernate and Jakarta Commons Logging.

根据我团队的经验，我们发现尝试在 OSGi 中处理 Web 内容很痛苦。其他痛点是 Hibernate 和 Jakarta Commons Logging。

I find the OSGi specs pretty readable and I recommend you print out the flowchart that shows the algorithm for class loading. I'll guarantee you'll have moments of, "why am I getting a NoClassDefFoundError?": the flowchart will tell you why.

我发现 OSGi 规范非常易读，我建议您打印出显示类加载算法的流程图。我保证您会有“为什么我会收到 NoClassDefFoundError 错误？”的时刻：流程图会告诉您原因。

回答by Andreas Kraft

There are a couple of thinks to keep in mind if you are starting with OSGi.

如果您开始使用 OSGi，有几个想法需要牢记。

As mentioned elsewhere in this thread, knowing about classloading is really important. In my experience everybody sooner or later runs into problems with it.

正如本主题其他地方所提到的，了解类加载非常重要。根据我的经验，每个人迟早都会遇到问题。

Another important thing to remember is: never hold references! Have a look at the whiteboard pattern on which the services concept of OSGi is build (see the link in one of the other answers).

另一件要记住的重要事情是：永远不要持有引用！查看构建 OSGi 服务概念的白板模式（请参阅其他答案之一中的链接）。

In my experience you should not try to convert a monolitic application into an OSGi-based one. This usually leads to a badly and unmanageable mess. Start anew.

根据我的经验，您不应该尝试将单体应用程序转换为基于 OSGi 的应用程序。这通常会导致严重且无法管理的混乱。重新开始。

Download one of the freely available stand-alone OSGi implementations. I found Knopflerfish rather good and stable (I use it in many projects). It also comes with lots of source code. You can find it here: http://www.knopflerfish.org

下载免费提供的独立 OSGi 实现之一。我发现 Knopflerfish 相当好且稳定（我在许多项目中使用它）。它还附带了大量的源代码。你可以在这里找到它：http: //www.knopflerfish.org

Another good tutorial can be found here. https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

另一个很好的教程可以在这里找到。https://pro40.abac.com/deanhiller/cgi-bin/moin.cgi/OsgiTutorial

Peter Kriens of the OSGi Alliance gave a nice interview: http://www.infoq.com/interviews/osgi-peter-kriens. His homepage and blog (which is always a good read can be found here: http://www.aqute.biz

OSGi 联盟的 Peter Kriens 接受了很好的采访：http: //www.infoq.com/interviews/osgi-peter-kriens。他的主页和博客（总是很好的阅读可以在这里找到：http: //www.aqute.biz

回答by dlinsin

I really like the Apache Felix tutorials. However, I think in general leveraging OSGi in your application isn't one of those "let's use this framework, because it's hype" decision. It's more of a design question, but then everything that OSGi gives you in terms of design, you can have with vanilla Java as well.

我真的很喜欢Apache Felix 教程。但是，我认为一般来说，在您的应用程序中利用 OSGi 不是“让我们使用这个框架，因为它是炒作”的决定之一。这更像是一个设计问题，但是 OSGi 在设计方面为您提供的一切，您也可以使用 vanilla Java。

As for the runtime, you cannot just add an existing application and make it OSGi enabled. It needs to be design to be dynamic. Spring DM makes it easy to hide that from you, but it's still there and you need to be aware of it.

至于运行时，您不能只添加现有应用程序并使其启用 OSGi。它需要被设计成动态的。Spring DM 使您可以轻松地将其隐藏起来，但它仍然存在，您需要注意它。