Hi Peter, Thanks for the response. I am glad we are on the same page, despite some generation gap :). I will start an application note on the web page git.
PS: you are spot on with "composition." my favorite OO pattern. I don't use inheritance that much. Also DS+configuration really difficult to understand especially with dynamic references and component life cycle. Yet it is great way to write "configuration driven" software. BTW i am working on an iot framework just doing that. I think it would be good to look at DS+configuration in another application note sometime in the future. 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 08:41 PM To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Subject: Re: [osgi-dev] Ambiguity when providing DS components? Can I suggest you start an OSGi enRoute Application Note? On 29 aug. 2016, at 12:13, Daghan ACAY <daghana...@hotmail.com<mailto:daghana...@hotmail.com>> wrote: 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. Yes, but it also drags in an injection engine. I am still very fond of new because I know what I get but it might be a generational thing. 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. This can also be handled with normal packages, unless you have several of course but then the substitution rule kicks in for me. 3- whiteboard pattern needs to be used. E.g. if you need to act on multiple implementations as a framework. Yes, especially the fact that you do not really care if there is zero, one, or many is very important. 4- components need to be created dynamically from configuration at runtime. Yes, this is what I would consider state but it is worth point this out specifically because DS + configuration is magic few people understand except for the ones that do and love it :-) 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 I guess you mean composition? I guess that makes sense, especially because you can also use things to wire together dynamically. Kind regards, Peter Kriens 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<mailto:peter.kri...@aqute.biz>> Sent: Monday, August 29, 2016 07:51 PM To: OSGi Developer Mail List <osgi-dev@mail.osgi.org<mailto: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<mailto:list+org.o...@io7m.com> wrote: > > 'Ello. > > On 2016-08-29T09:39:18 +0200 > Peter Kriens <peter.kri...@aqute.biz<mailto: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<mailto:osgi-dev@mail.osgi.org> > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto: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
