[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] OSGiServiceSupplier

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 :-)


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.

equinox-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit