OSGi绑定包的启动级别是如何定义的?

How is the OSGi bundle start level defined?

OSGi绑定包的启动级别是如何定义的?

I am using Apache felix and would like to persist the start level across framework executions. I do not anticipate a need to change the start level of a bundle very frequently at all an an entry in Manifest.MF seems the most sensible. I've to org.osgi.framework.startlevel but have not seen a practical example.

我正在使用Apache felix，并希望在框架执行过程中保持start级别。我不认为需要频繁地更改一个bundle的启动级别，而要更改Manifest中的一个条目。MF似乎是最明智的选择。我已经了解了org.osgi.frame .startlevel，但是还没有看到一个实际的例子。

I am also using maven with the maven-bundle-plugin, if there is an elegant way to incorporate the start level in the POM that would be brilliant.

我还在使用maven与maven-bundl -plugin结合，如果有一种优雅的方式在POM中合并开始级别，那将是非常棒的。

3 个解决方案

#1

Bundles don't define their own start level at build-time; the administrator or agent that installs the bundle into the framework defines it.

bundle在构建时不定义自己的启动级别;将bundle安装到框架中的管理员或代理将定义它。

The core framework defines a Start Level interface in section 8. Quoting:

核心框架在第8节中定义了一个开始级接口。引用:

The Start Level API provides the following functions:

启动级API提供以下功能:

• Controls the beginning start level of the OSGi Framework.

  控制OSGi框架的开始级别。

• Is used to modify the active start level of the Framework.

  用于修改框架的活动启动级别。

• Can be used to assign a specific start level to a bundle.

  可以用于将特定的启动级别分配给bundle。

• Can set the initial start level for newly installed bundles.

  可以为新安装的bundle设置初始启动级别。

The last two are relevant to your inquiry here. Section 8.3.4—Changing a Bundle's Start Level—indicates that the framework will store an assigned start level persistently.

最后两个问题与你的调查有关。第8.3.4节更改Bundle的启动级别—表示框架将持续地存储分配的启动级别。

If you're using Apache Felix, there are several ways you can install bundles and assign their start level, whether explicitly or by allowing them to inherit a default start level for installed bundles:

如果您正在使用Apache Felix，有几种方法可以安装bundle并分配它们的启动级别，无论是显式的还是允许它们继承已安装bundle的默认启动级别:

• Felix File Install (see the felix.fileinstall.start.level property, though it's not per-bundle)
• Felix文件安装(参见Felix .fileinstall.start。级别属性，虽然不是每个包)
• Felix Bundle Auto-Deploy (see the felix.auto.install.<n> property)
• Felix Bundle自动部署(参见Felix .auto.install。< n >属性)
• GoGo Shell Command (see the bundlelevel command)
• GoGo Shell命令(参见bundlelevel命令)

Also, see the felix.startlevel.bundle property, which controls bundles installed through means other than those above.

同时,看到felix.startlevel。bundle属性，它控制通过其他方式安装的bundle。

As for setting a manifest property (such as with Maven at build time), there used to be a way to do this in Equinox—now deprecated—but there is no standard means for a bundle to indicate to the framework what its proper start level should be.

至于设置manifest属性(比如在构建时使用Maven)，过去有一种方法可以在二分点(现在已经废弃了)进行此操作，但对于bundle来说，没有标准方法可以向框架表明其正确的启动级别是什么。

#2

X,

X,

I think there is an easier way to do what you're talking about. Currently, you are using the Felix OSGi implementation directly, which is very powerful. However, if you'd like the kind of granular control over bundle deployment, that's built into an OSGi container called Karaf. Think of Karaf as a car whose engine can be either Felix or Equinox. It something that rides on top of OSGi framework implementations and offers additional functionality. For example, Karaf provides a Provisioning mechanism. Deploying multiple bundles is called Provisioning. Because Provisioning isn't part of the OSGi spec, different OSGi containers implement provisioning in different ways. In Karaf, we do this through something called a features.xml file.

我认为有一种更简单的方法来做你正在谈论的事情。目前，您正在直接使用Felix OSGi实现，它非常强大。但是，如果您想要对bundle部署进行粒度控制，那么可以将其构建到一个名为Karaf的OSGi容器中。把Karaf想象成一辆发动机可以是Felix或者Equinox的汽车。它依赖于OSGi框架实现并提供附加功能。例如，Karaf提供了一个供应机制。部署多个bundle称为供应。由于供应不是OSGi规范的一部分，不同的OSGi容器以不同的方式实现供应。在Karaf，我们通过一种叫做特征的东西来实现这一点。xml文件。

In a features.xml file, you identify a specific set of bundles you want deployed together. Then you name that group. In this file you can also identify the specific start order you'd like Karaf to deploy the bundes.

在一个特性。xml文件，您确定您想要部署在一起的一组特定的包。然后给这个组命名。在这个文件中，您还可以确定您希望Karaf部署bundes的特定启动顺序。

A word on OSGi start-orders. A bundle cannot be started until all mandatory wiring has occured. This means that you can define a start order, but OSGi takes this as guidances, not mandatory. For example, if you have a bundle A that requires an import of bundle b's "foo" package, you can tell the container to start A before B all you want. But it won't respect that order because in reality B needs to be started in order to A to start. Its ok though, the container knows (usually) what order to start bundles in.

一个关于OSGi启动顺序的词。在发生所有强制连接之前，不能启动bundle。这意味着您可以定义一个开始顺序，但是OSGi将此作为指导，而不是强制的。例如，如果您有一个bundle a需要导入bundle b的“foo”包，您可以告诉容器在b之前启动a。但是它不尊重这个顺序因为实际上B需要开始才能开始A。不过没关系，容器(通常)知道启动包的顺序。

The rub comes in the use of optional versus mandatory imports in a bundle. If your bundle imports b.foo, but that import is optional, the container will respect the bundle start order (A then B). But watch out, if A actually needs to import b.foo, but you've marked it as optional, A will start without Wiring to b.foo, and A will throw a ClassNotFoundException. This nasty little bug can occur when using the various packages in Spring.

困难在于在包中使用可选导入和强制导入。如果您的包导入b。foo，但是那个导入是可选的，容器会尊重bundle start order (A然后B)，但是要小心，如果A实际上需要导入B。foo，但是你把它标记为可选的，A将不会连接到b。foo和A会抛出ClassNotFoundException。当在Spring中使用不同的包时，会出现这种讨厌的小错误。

To make your life easy, Spring does the majority of its imports as "optional". If a given spring bundle actually needs to resolve a dependancy before working and that import is marked as optional, your bundles will deploy sparodically. Of course,the fix for this is to create a bundle fragment that modifies the bundle imports to "mandatory", but that's really beyond the scope of your question.

为了让您的生活更轻松，Spring的大多数导入都是“可选的”。如果给定的spring bundle在工作之前确实需要解决依赖关系，并且该导入被标记为可选的，那么您的bundle将以稀疏方式部署。当然，解决这个问题的方法是创建一个bundle片段，将bundle导入修改为“mandatory”，但这实际上超出了您的问题范围。

I hope this clarifies things for you.

我希望这能让你明白事理。

#3

bundle.adapt(BundleStartLevel.class).setStartLevel(startlevel);