There is no clear cut test to see what is a component. I use the following heuristics:
a) Does it have state? For example, Configuration Admin. In those case you want
to share a single object between different bundles
b) Do I want to add some type to the system with a bundle. I.e. implementations
are in different bundles. When they are all in the same bundle and you do not
see a future where you would deliver different impls in a bundle a service is
not needed
c) Does it have an interesting life cycle? Services are wonderful things to
signal availability
In your case, the simple approach without a service seems the best choice. Just
using ’new’ is imho the simplest of all solutions. You only want to go to a
factory model if the selection process is complicated or you want to hide the
implementations.
Kind regards,
Peter Kriens
> On 29 aug. 2016, at 11:46, list+org.o...@io7m.com wrote:
>
> '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
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
