所以我想解释它的最好方法是用例子。
发布服务 X 时,需要注册它的一个实例。对于许多客户来说,同样的例子回答了它。
我想知道是否有办法按需实例化它的许多实例。就像客户端 c1 请求实例 x1 下的服务 X 一样,客户端 c2 与实例 x2 通信,处理后每个实例都被销毁。
因为它适用于 Web 服务器。每个客户端方法调用都是一个请求,在它响应之后,该请求被销毁。
我看到了一些关于多个参考的答案,但我不太确定它们是否都是我的同一个问题。
谢谢
所以我想解释它的最好方法是用例子。
发布服务 X 时,需要注册它的一个实例。对于许多客户来说,同样的例子回答了它。
我想知道是否有办法按需实例化它的许多实例。就像客户端 c1 请求实例 x1 下的服务 X 一样,客户端 c2 与实例 x2 通信,处理后每个实例都被销毁。
因为它适用于 Web 服务器。每个客户端方法调用都是一个请求,在它响应之后,该请求被销毁。
我看到了一些关于多个参考的答案,但我不太确定它们是否都是我的同一个问题。
谢谢
几年前,我尝试在 RFC Genuine Service Factories 中以通用的方式回答这个问题。经过深思熟虑,我得出结论,解决方案非常简单。只需注册工厂服务。因此,如果您希望能够创建 Foo,只需注册一个 FooFactory 服务......这允许您拥有参数、类型安全等所有优点。如果想要一个通用解决方案,只需创建一个工厂类型:
public interface Factory<T> { T create(); }
@Component
public class FooFactoryImpl implements Factory<Foo> {
public Foo create() { ... }
}
但是,我发现最好的方法就是创建一个 FooFactory ,因为这为您提供了类型安全性,因为泛型类型往往需要强制转换。它还为您提供了可扩展性、参数以及最重要的语义的正确文档。
All the other solutions I know tend to suffer from heavy casting and bypassing the type system. The factory components in Declarative Services are a point in case. I think the responsibility of the OSGi service registry is to give you a handle. As with all technologies it is very tempting to add additional semantics since it is often close. I think this is a case that is much better left to Java than to OSGi. keep it simple.
OSGi 当前支持ServiceFactory,它允许提供者为每个消费者捆绑包创建一个唯一的服务实例。这可能足以满足您的需求
但它不允许提供者为捆绑中的每个服务请求提供唯一的服务实例。我正在为 R6 制定一项提案,以允许为每个请求创建唯一的服务实例。希望它将被 R6 规范接受。