Yes. If you called getService and received a non-null, but no longer need the
service object, then you should unget.
Failing to do so will not exactly cause a memory leak but it may be
“unfriendly”. For example, suppose that a provider is using a ServiceFactory,
and the object it allocates for each consumer bundle is expensive. By
ungetting, you give the provider an opportunity to reclaim those resources.
The case is less compelling for ordinary singleton services… but remember, as a
consumer you don’t know if the provider is a singleton or a factory, it’s an
implementation detail of the provider. So it’s better to do the right thing all
the time.
Neil
On 27 August 2014 at 01:09:26, Raymond Auge ([email protected]) wrote:
What about if I'm in a STC or ST and decide to return null to indicate I choose
to not track the service, I suppose I should also ungetService (if I did call
getService() ) before returning?
- Ray
On Tue, Aug 26, 2014 at 4:53 PM, BJ Hargrave <[email protected]> wrote:
If the ServiceTrackerCustomizer (STC) or the equivalent methods on
ServiceTracker (ST) gets the service, it must also unget the service. Balance.
So I would say it is bad form to not call ungetService on remove if getService
was called on add.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 2014/08/26 17:13
Subject: [osgi-dev] calling bundleContext.ungetService()
Sent by: [email protected]
Hey all,
I'd like some help to settle an internal debate.
Is it bad form to NOT call bundleContext.ungetService() from a service tracker?
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Raymond Augé (@rotty3000)
Senior Software Architect
Liferay, Inc. (@Liferay)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
