Jboss osgi服务的多个版本

我有osgi服务service-1.0.0.jar和service-1.1.0.jar，它们是service-api-1.0.0.jar的实现

这两个service-1.0.0.jar和service-1.1.0.jar具有相同的服务名称和包

服务由bundle activator注册

假设bundle activator是com.abc.xyz.MyActivator-1.0.0和1.1.0

我面临的问题是，当我在我想要的版本上部署这些服务并使用服务跟踪器和过滤器进行查找时，无论选择哪个版本，我都会得到相同的实现

这让我相信，我试图实现的目标是行不通的。 我需要将多个服务实现打包在不同版本的单独包中，并且能够在运行时动态选择

我正在jboss-6.1.1 eap中尝试此功能

如果我在版本中保留不同的包名，看起来它能够理解这是两个不同的服务，但当包名相同时，我得到相同的服务实现

我做错什么了吗？有人试过这个吗

OSGI允许您部署多个版本的服务是正确的吗

在1.0.0和1.1.0中使用MyActivator的唯一包名后更新，看起来服务能够保持唯一性。

---

这是否意味着Activators必须在bundle中唯一？

我假设

service-api-1.0.0.jar

导出定义服务接口的包。在这种情况下，听起来您有两个相同版本服务的实现。不同版本的服务没有不同的实现。因此，从服务用户的角度来看，这些服务是相同的：它们来自相同的服务api包版本。

我认为您以一种奇怪的方式使用OSGi服务。作为客户机，您不应该查看实现包来确定版本或其他信息

相反，您应该使用服务接口和服务属性来区分服务

例如，您可以拥有一个属性版本，并发布第一个版本为1的服务和第二个版本为2的服务。然后可以筛选此属性以获得特定服务

---

使用反射也是一件很不寻常的事情。最好在接口包中提供用于在客户端和服务之间交换数据的类。这将减少客户机对服务impl的依赖。

如果您有同一服务API的多个实现，并且客户机查询服务API的实现，则它可以获得任何实现。这很好，因为客户不应该在意

例如，假设您有一个

问候语

接口，其中有多个实现注册为服务，可能是通过多个bundle注册的。如果客户要求OSGi提供

问候

服务，那么OSGi只需选择一个即可。毕竟，如果您只是请求一个

问候语

，而没有指定任何其他内容，那么您应该接受任何实现。客户当然不应该关心服务来自哪个特定捆绑包：这就是解耦的本质

顺便说一句，当这种情况发生时，OSGi通常会选择首先注册的实现（实际上是具有最低

service.id

的实现，它是一个不断递增的数字，因此实际上是相同的）。这可能就是为什么OSGi总是选择一种特定的服务

---

如果您的客户机需要区分服务实现，那么您可以向已发布的服务添加属性，并对这些服务进行筛选。例如，一个捆绑包可以发布属性为

language=en_US

（即美国英语）的问候语服务，另一个捆绑包可以发布属性为

language=de

的问候语服务。如果您的客户只需要英语问候语，则可以使用类似

（language=en*）的过滤器

如何筛选版本？您可以使用OBJECTCLASS进行筛选，获取所有服务引用，然后迭代并执行bundle.getVersion之类的操作，只要包是私有的，激活器名称在bundle之间就不必是唯一的。通常，您应该尝试通过不导出包来隐藏服务的实现。这很有意义。默认情况下，我的activator包已导出。我非常感谢你的正确答案。我错过了私人软件包：com.app.service.impl我希望我能投票给你的答案。这不是那么直截了当的。在这种情况下，客户端不导出任何内容。客户机和服务之间存在松散耦合。客户端只知道服务名称和版本，所以客户端不知道服务的Java类型？这种类型不是由服务api导出的，而是由客户端导入的？对！客户端正在使用反射。看起来我正在尝试做的应该是可行的？请在为Activators使用唯一的软件包名称后检查我的更新只有一切似乎都可行您是说一个可以对一个服务api实现一个实现吗？我正试图进行完全相反的测试，我需要同一服务api的多个实现。可能是我缺少OSGi服务背后的基本理念。你能多解释一下吗？顺便说一句，你是对的，我的方法很奇怪，但这是因为我们的自定义框架在运行时动态解析服务实现。。。您可以拥有任意数量的API。同一API可以有多个实现。我想表达的是，如果您不想通过反射或类似方式查看impl，您将需要（例如）服务属性来区分实现。这正是我所做的，但我缺少私有包声明，这导致我的服务行为怪异。所以，当我注册我的新服务时，它是注册相同的旧服务