Re: [equinox-dev] OSGiServiceSupplier

> short-comings you mention in your blog. > > Finally I do thank you for proposing a solution to a problem and bringing it > here for discussion, I just don't feel comfortable with the current solution > :-) > > Tom > > > > > > From: Alex

Re: [equinox-dev] OSGiServiceSupplier

>> I also wonder if the latest DS specification helps deal with some of the >> short-comings you mention in your blog. >> >> Finally I do thank you for proposing a solution to a problem and bringing it >> here for discussion, I just don't feel comfortable wi

Re: [equinox-dev] OSGiServiceSupplier

to a problem and bringing it here for discussion, I just don't feel comfortable with the current solution :-) Tom From: Alex Blewitt <alex.blew...@gmail.com> To: Equinox development mailing list <equinox-dev@eclipse.org> Date: 09/25/2015 01:33 PM Subject:

[equinox-dev] OSGiServiceSupplier

I posted on http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.html earlier today about using Java 8’s Supplier to acquire a service on-demand without having to do expensive client-side coding, and that would fail fast in

Re: [equinox-dev] OSGiServiceSupplier

if you know for a >>> fact that the service you are getting is not stateful and does not >>> use a ServiceFactory. Or if you make sure to use the OSGiTracker in >>> an object that has a one-to-one relationship with the active >>> lifecycle of the bundle. I a

Re: [equinox-dev] OSGiServiceSupplier

it to the client >>>> code for its first usage. In general this is not using good >>>> practices in OSGi because the service registration may be using a >>>> ServiceFactory that needs to track the state of the using bundles. >>>> Such usage on a Se

Re: [equinox-dev] OSGiServiceSupplier

. So if you use the OSGiTracker in a short lived object >>>>> that gets created often then you will quickly grind the service event >>>>> bus of the framework to a halt. You may try to limit the damage of >>&g