我是 OSGi 的新手，但它很有趣。
osgi 包和 java 应用程序之间可以交互吗？如果可以的话，如何实现？
谢谢！
背景是我有一个大型 Java SE 应用程序（作者是另一位程序员），具有许多依赖项。首先，我的目标是添加新功能，其次是更改架构。我将尝试使用 OSGi，但我不想编写两次代码，因此我想现在将新代码编写为捆绑包。但可以使用旧应用程序中的这个新功能。
I'm new whith OSGi, but it is interesting.
Is it possible to interact between osgi bundles and java application? If it is possible, how?
thanks!
The context is that I have a big Java SE application(author is another programmer) with many dependencies. First my goal is to add new functionality and second - change architecture. I'll try to use OSGi, but I don't want to write code twice, for that reason I want to write new code now as bundles. But use this new functionality from the old application.
发布评论
评论（3）
是的！是的！是的！这是开始利用 OSGi 并向基于服务的应用程序发展的完美方式。
使用 4.2 启动器 API 创建框架非常简单，甚至无需知道您使用哪个框架实现。您将获得一个 Framework 对象，它实际上是一个 OSGi Bundle，并且可以为您提供 BundleContext。您可以使用它来安装捆绑包。这一切都在规范中进行了描述，但您可以在 Felix 中找到很多具体且优秀的示例：http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html。 Felix 从第一天起就明确提倡嵌入应用程序。
这种方法的困难部分是适应模块化及其限制。为了发挥作用，您必须在 OSGi 包和您的应用程序之间共享类；这需要使用 org.osgi.framework.systempackages.extra 属性从应用程序中显式导出这些共享包。此属性是应用程序的 Export-Package 标头。
由于 Java 中的类加载模型，无法从框架中的包导入包。这意味着您的应用程序代码只能使用框架中的服务，其中这些服务的包位于应用程序类路径上。
这样做的结果是，新功能往往会转移到具有完全可见性的捆绑包：导出的应用程序包以及任何捆绑包。然而，这可能正是您想要的。
因此，请注意这个潜在的陷阱。嵌入，然后随着时间的推移将所有代码迁移到捆绑包中，以便您的应用程序仅成为 OSGi 启动器。但是，请务必注意两个环境之间共享的包。
祝你好运，让我们知道进展如何。
Yes! Yes! and Yes! This is a perfect way to start taking advantage of OSGi and evolving towards a service based application.
It is trivial to create a framework with the 4.2 launcher API without even knowing which framework implementation you use. You get a Framework object then that is actually an OSGi Bundle and can provide you with a BundleContext. This you can use to install bundles. This all is described in the spec but you can find a lot concrete and excellent examples in Felix: http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html. Felix has been explicitly promoting embedded in apps since day one.
The hard part of this approach will be getting used to modularity and its restrictions. To be useful, you will have to share classes between OSGi bundles and your application; this requires explicit exporting of these shared packages from your application using the org.osgi.framework.systempackages.extra property. This property is the Export-Package header for your application.
Importing packages from bundles in the framework is not possible due to the class loading model in Java. This means your application code can only use services from the framework where the packages for those services are on the apps classpath.
The result of this is that new functionality tend to drift to bundles where there is full visibility: both the exported app packages as well as any bundles. However, this is probably exactly what you want.
So be aware of this potential pitfall. Embed, and then over time migrate all your code to bundles so that your application becomes only an OSGi launcher. However, be very aware of your the packages shared between the two environments.
Good luck and let us know how this goes.
我将 OSGi 视为一种结构化技术。您可以使用它来定义应用程序的组件结构。因此，您的所有应用程序实际上都是 OSGi 包的集合。因此，交互不是问题，只是应用程序的不同部分以正常方式交互。
[编辑以下评论澄清。]
您有一个基本决定：您的 OSGi 代码将在与原始进程相同的进程中执行还是在单独的进程中执行？
分离意味着可以自由地利用 OSGi 来构建新代码，但代价是进程间通信的复杂性和性能开销。您很可能最终会对现有应用程序进行重大更改，以支持某种形式的远程处理。我不认为这是一个很好的方法，除非您的 OSGi 代码恰好是其他远程客户端可能会使用的某种可重用服务。
如果在同一过程中，那么我会说您需要硬着头皮说这将是一个 OSGi 应用程序。使用现有应用程序并使其在 OSGi 中运行不需要付出太多的努力。
假设您将现有应用程序视为一个巨大的 OSGi 包？初始化方面会有一些工作，但其余的工作会“正常工作”吗？如果您将此作为第一步，那么现有应用程序的真正重新架构和模块化就会被推迟。然后，您只需公开新模块所需的接口，并在必要时使用新模块提供的服务。通过构建依赖关系，您可以立即获得 OSGi 的好处。
I see OSGi as a structuring technology. You can use it to define the component structure of your application. So all of your app is effectively a collection of OSGi bundles. Hence interaction is not a problem, just different bits of your app interating in the normal way.
[Edited following comment clarification.]
You have a fundamental decision: is your OSGi code going to execute in the same process as the original or in a seperate process?
Separation implies freedom to structure the new code as you wish, exploiting OSGi, but at the cost of interprocess communication complexity and performance overheads. It's pretty likely that you will end up making substantial changes to the existing app in order to support remoting in some form. I don't see this as a great approach unless your OSGi code happens to be some kind of re-usable service that perhaps other remote clients would use.
If in the same process then I'd say that you need to bite the bullet and say that this is going to be a OSGi application. The amount of effort to take an existing app and make it run in OSGi need not be excessive.
Suppose you treated the existing application as one huge OSGi bundle? There would be some work on initialisation, but would the rest "just work"? If you do this as the first step then the real re-architecting and modularisation of the existing app is deferred. You then just expose the interfaces your new modules need, and where necessary consume services provided by the new modules. Immediately you are getting OSGi benefits by structuring the dependencies.
使用 OSGi 构建的应用程序可以像两个普通 (Java) 应用程序一样进行交互。因此，通过加载/保存文件。或者，当其中一个被创建为 OSGi http 服务器时，只需通过 http 与该 (OSGi) 服务器进行通信。就像您以前所做的那样，不包括 OSGi。
An application build with OSGi can interact in the same way as just two normal (Java) applications. So, by loading / saving files. Or when one of them is created as an OSGi http server, then just communicate through http with that (OSGi) server. Just think of it as you used to do, without OSGi included.