'Ello. On 2016-08-29T09:39:18 +0200 Peter Kriens <peter.kri...@aqute.biz> wrote:
> It depends on how extensible you want to be … > > If you want to provide different implementations for the same type in > different bundles then a solution is that each implementation bundle > registers a service that acts as a factory. You design some service > properties for the selection. That's pretty much what I've done, isn't it? Not sure if you were referring to a different technique. As for the service properties, would these be capabilities? I think my main question is what implementation is selected if no properties are defined and there's nothing in the manifest to indicate a preference of one implementation over the other. I've read through the spec and it doesn't seem to talk about this, so I assume that it's implementation-defined. > However, this sounds like overkill. What would the problem be to just export > the supplier package and let the user create the instance directly like in > classic Java? Why does it have to be a component? > I suppose it doesn't *have* to be a component. I don't have enough practical experience with OSGi to know what should be and shouldn't be. I agree that I could export the supplier package to at least give OSGi users the option to instantiate statically. I introduced a component for the same reason that I assume anyone would introduce a component... To decouple use of the trees from the selection of implementations, and to make live upgrades easier. M
pgpOaIpfk3wC_.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
