Hi Peter, In addition to your heuristics I generally use services if:
1- testability is important e.g. testing a class which uses "new" for creating some functional entity is very hard. Easiest way to provide dependency injection is services. 2- service implementations should be changed at runtime e.g. if a backward compatible new version is available at runtime then references can get the latest version dynamically. 3- whiteboard pattern needs to be used. E.g. if you need to act on multiple implementations as a framework. 4- components need to be created dynamically from configuration at runtime. 5- a class or method is likely to be extended with new functionally using other components but api cannot change e.g. dependency injection at imlepenting class without changing the api. Do you think these are complementary to your initial heuristics? Actually i would very much like if we can ask the community to compile a coherent list with code examples. I am sure this will help a lot of osgi practitioners including myself. Best regards Daghan Sent by MailWise<http://www.mail-wise.com/installation/2> – See your emails as clean, short chats. -------- Original Message -------- From: Peter Kriens <peter.kri...@aqute.biz> Sent: Monday, August 29, 2016 07:51 PM To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Subject: Re: [osgi-dev] Ambiguity when providing DS components? 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
