Re: [equinox-dev] OSGiServiceSupplier

["Thomas Watson" <tjwatson@xxxxxxxxxx>]

I have some issues with both examples you
gave.  For the code that uses ServiceTracker it will end up creating
a ServiceTracker and never closing it which will leave a ServiceListener
leaked (registered) with the framework for the lifetime of the active bundle.
 Once the bundle 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 the damage of that
leak by having a finalize() method that closes the tracker, but usually
finalize() methods are not recommended best-practice.

The OSGiSupplier is better but it has
the unfortunate side-effect of ungetting the service object before even
returning 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 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 service object is
thrown away by the framework, then on next usage the service object will
have to be recreated by the factory.  This could result in a performance
issue if the creating of the service 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 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 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
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 with the current solution :-)

Tom





From:      
 Alex Blewitt <alex.blewitt@xxxxxxxxx>
To:      
 Equinox development
mailing list <equinox-dev@xxxxxxxxxxx>
Date:      
 09/25/2015 01:33 PM
Subject:    
   [equinox-dev]
OSGiServiceSupplier
Sent by:    
   equinox-dev-bounces@xxxxxxxxxxx

---

I posted on http://alblue.bandlem.com/2015/10/osgi-services-in-java-8.htmlearlier 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 the absence of any OSGi classes and return null in such situations.

I’d like to contribute this to Eclipse so that it can
be used in places where Declarative Services aren’t the right solution
(specifically; for integrating in where places have static Log or DebugOptions
classes).

Which would be the right project/bundle to contribute
this into? Clearly it could go into something like Platform or Core.runtime,
but I wondered if it might be sensible to have this in equinox.util or
equivalent.

Alex_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev