Can I suggest you start an OSGi enRoute Application Note? > On 29 aug. 2016, at 12:13, Daghan ACAY <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>
> 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
> > <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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
