[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] bug or not
|
I'd agree if you are using a service constantly, it doesn't makes sense to release it after each use. It is less clear when it is not a constant need.
Of course, HttpService perhaps causes acute pain since it is from a time before the whiteboard pattern...
-> richard
On Apr 28, 2014 9:54 PM, "Thomas Watson" <
tjwatson@xxxxxxxxxx> wrote:
I meant for any service that maintains state for the duration of usage for each using bundle. Luckily that is not common for the services that the OSGi specification defines. HttpService is probably the most commonly used one that has to maintain state for using bundles. Regardless of that, using a pattern that will constantly get/unget the same service over and over cannot perform as well as using some higher level API like SerivceTracker or declarative models like DS, or if you must use raw BundleContext APIs then caching it yourself. If it is a rarely used service and you don't need it that often then I guess using the get/unget each time is not that costly, but it still does not seem like something we would want to recommend for services that are often used. Regardless of how cheap it is to construct there is still more code you have to run to construct and get it each time.
Tom
Richard Hall ---04/28/2014 08:08:47 PM---If you only meant for registering resources with the HttpService, then i can agree with that. :-)
From: Richard Hall <heavy@xxxxxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 04/28/2014 08:08 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-bounces@xxxxxxxxxxx
If you only meant for registering resources with the HttpService, then i can agree with that. :-)
-> richard
On Apr 28, 2014 8:59 PM, "Thomas Watson" <tjwatson@xxxxxxxxxx> wrote:
But for the HttpService I consider this an anti-pattern. When a bundle's usecount reaches zero the HttpService implementation must unregister all resources registered by that bundle. If that is really what the webconsole bundle wants then that is fine and I agree with you. But if the webconsole has resources (servlets) it does not want unregisered then it better keep its usecount of the service (it is still using to serve resources) greater than zero.
Tom
"Richard S. Hall" ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: >
From: "Richard S. Hall" <heavy@xxxxxxxxxxxxxx>
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date: 04/28/2014 05:34 PM
Subject: Re: [equinox-dev] bug or not
Sent by: equinox-dev-bounces@xxxxxxxxxxx
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
_______________________________________________
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
_______________________________________________
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
