Re: [equinox-dev] OSGiServiceSupplier

dle is stopped the leaked listeners will finally >>>>> get cleared. 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 th

Re: [equinox-dev] OSGiServiceSupplier

iceFactory that needs to track the state of the using bundles. >>>> Such usage on a ServiceFactory registration will cause the service >>>> usecount for the bundle to osilate between one and zero within the >>>> get() method. Each time the usecount goes to zero the s

Re: [equinox-dev] OSGiServiceSupplier

object is >>> expensive. >>> >>> The classes may have their uses in specific cases and not cause >>> issues if used in a specific way. For example, if you know for a >>> fact that the service you are getting is not stateful and does not >>&

Re: [equinox-dev] OSGiServiceSupplier

t; one-to-one relationship with the active lifecycle of the bundle. I am not >> sure they belong down in Equinox though because I do not believe they >> promote best-practices when dealing with the OSGi service registry. >> >> I also wonder if the latest DS specification

Re: [equinox-dev] OSGiServiceSupplier

on 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 Blewitt > To:

Re: [equinox-dev] OSGiServiceSupplier

a problem and bringing it here for discussion, I just don't feel comfortable with the current solution :-) Tom From: Alex Blewitt To: Equinox development mailing list Date: 09/25/2015 01:33 PM Subject:[equinox-dev] OSGiServiceSupplier Sent by:equinox-dev

[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 th