On 4/28/14, 17:37 , Thomas Watson wrote:
Is your
ServiceFactory.ungetService getting called each time? If so
then it is likely the felix webconsole is using an anti
pattern like this:
HttpService service =
bc.getService(httpServiceRef);
/// do some work with http
service
bc.ungetService(httpServiceRef);
Is this really an anti-pattern? It doesn't seem so to me. If so, why
don't we just deprecate ungetService() and tell all bundle
implementers to not worry about ungetting, since they framework will
do it for you when the bundle stops?
The fact that ungetting and recreating may be costly is an issue for
the service implementer, it would seem, not the service consumer. If
it costs a lot to create instances, the service factory could
consider doing caching of instances and reusing them on subsequent
requests.
Having client bundles call ungetService when they are done with a
service that they may not use again for a while seems reasonable to
me.
-> richard
If they are getting/ungetting
the service each time they are interacting with the service
then the usecount for the service goes to zero for each usage
which then causes the framework to free the service instance
object. The should be using something like a ServiceTracker
to avoid this kind of anti-pattern.
Tom
Raymond Auge
---04/28/2014 04:26:50 PM---I agree that I should NOT have to
implement this code. However, I'm having to do so in order to
work
From: Raymond Auge
<raymond.auge@xxxxxxxxxxx>
To: Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>
Date: 04/28/2014 04:26 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-bounces@xxxxxxxxxxx
I agree that I should NOT have to
implement this code. However, I'm having to do so in order to
work around this apparent issue.
- Ray
On Mon, Apr 28, 2014 at 5:23 PM,
Raymond Auge <raymond.auge@xxxxxxxxxxx> wrote:
--
Raymond
Augé (@rotty3000)
Senior Software Architect
Liferay,
Inc. (@Liferay)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|