OSGi 中有没有一种方法可以确保一次只有一个事物可以访问服务？
我有一个定义系统中设备的接口。这些设备一次只能由一个实体使用。我想将每个设备注册为 OSGi 服务，以便其他人可以通过该机制（使用声明性服务或服务跟踪器）访问设备。然而，据我所知，该机制允许所有实体请求相同的服务。
有没有办法让第一个请求者获得服务或者使用声明式服务只让一个服务组件得到满足？
I have an interface that defines a device in a system. The devices are intented to be used by only one entity at a time. I would like to register each device as an OSGi service so others can access the devices through that mechanism (using Declarative Services or a service tracker). However, that mechanism as far as I know, allows all entities to request the same service.
Is there a way for only the first requester to get the service or using Declarative Services only have one service component become satisfied?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用ServiceFactory来实现设备服务。然后，您可以向每个包返回一个唯一的服务对象，然后使用该对象来序列化访问。或者，如果当前有任何其他捆绑包可以访问该服务，则您的 ServiceFactory 可能会向其他捆绑包返回 null。
使用 ServiceFactory 可以让您的服务实现了解哪些捆绑包正在使用该服务，并对它们的使用进行一些控制。
Use a ServiceFactory to implement the device service. You can then return a unique service object to each bundle and then use that object to serialize access. Alternately your ServiceFactory could return null to other bundles if there is any other bundle which currently has access to the service.
Using a ServiceFactory allows your service implementation to know what bundles are using the service and to exert some control over their use.
AFAIK 你不能使用 DS 来实施单一的消费者政策。
乍一看ServiceFactory可能 有效，如果有效的话将是最简单的方法。
但是有一个 警告：
“框架会缓存返回的值（除非它为空），并且在以后对同一包调用 BundleContext.getService 时将返回相同的服务对象。这意味着框架不得允许同时调用此方法 我所以我认为它会在以下情况下失败：
框架的缓存很可能会干扰并给 A 缓存的 S，即使它已经被 B 持有。
能想到的唯一替代方案是使用FindHook,虽然这有点低级，你可能想实现其他 钩子（EventHook、ListenerHook）完整性。
使用挂钩，您将能够屏蔽其他捆绑包的服务可用性。尽管由于您的钩子将保持状态，您将希望它与设备服务位于同一个包中，这样在不停止设备服务的包的情况下就不可能停止钩子。
AFAIK you can't use DS to impose a single consumer policy.
At first glance a ServiceFactory might work and if it did would be the simplest way to go.
However there's one caveat:
"The Framework caches the value returned (unless it is null), and will return the same service object on any future call to BundleContext.getService for the same bundle. This means the Framework must not allow this method to be concurrently called for the same bundle"So I think it will fail in the following scenario:
The framework's cache may well interfere and give A the cached S even thought it is already held by B.
The only alternative I can think of is to use a FindHook, though this a bit more low-level, and you'd probably want to implement the other hooks (EventHook, ListenerHook) for completeness.
Using the hooks you'll be able to mask the services availability to other bundles. Though as your hook will be holding state you'll want it in the same bundle as the device service so that it's impossible to stop the hook without stopping the device service's bundle.