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" <tjwat...@us.ibm.com> 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
>
>
>
> [image: Inactive hide details for Richard Hall ---04/28/2014 08:08:47
> PM---If you only meant for registering resources with the HttpSer]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 <he...@ungoverned.org>
> To: Equinox development mailing list <equinox-dev@eclipse.org>
> Date: 04/28/2014 08:08 PM
> Subject: Re: [equinox-dev] bug or not
> Sent by: equinox-dev-boun...@eclipse.org
> ------------------------------
>
>
>
> 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"
> <*tjwat...@us.ibm.com*<tjwat...@us.ibm.com>>
> 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
>
>
>
> [image: Inactive hide details for "Richard S. Hall" ---04/28/2014
> 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote: >]"Richard S.
> Hall" ---04/28/2014 05:34:25 PM---On 4/28/14, 17:37 , Thomas Watson wrote:
> >
>
> From: "Richard S. Hall" <*he...@ungoverned.org* <he...@ungoverned.org>>
> To: Equinox development mailing list
> <*equinox-dev@eclipse.org*<equinox-dev@eclipse.org>
> >
> Date: 04/28/2014 05:34 PM
> Subject: Re: [equinox-dev] bug or not
> Sent by: *equinox-dev-boun...@eclipse.org*<equinox-dev-boun...@eclipse.org>
> ------------------------------
>
>
>
> 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
>
>
>
> [image: Inactive hide details for Raymond Auge ---04/28/2014
> 04:26:50 PM---I agree that I should NOT have to implement this code.
> Howev]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.a...@liferay.com>*<raymond.a...@liferay.com>
> To: Equinox development mailing list
> *<equinox-dev@eclipse.org>*<equinox-dev@eclipse.org>
> Date: 04/28/2014 04:26 PM
> Subject: Re: [equinox-dev] bug or not
> Sent by:
> *equinox-dev-boun...@eclipse.org*<equinox-dev-boun...@eclipse.org>
>
>
> ------------------------------
>
>
>
> 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.a...@liferay.com* <raymond.a...@liferay.com>> wrote:
>
>
>
> On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson <
> *tjwat...@us.ibm.com* <tjwat...@us.ibm.com>> wrote:
> You seem to be implementing the work that the framework
> already does for ServiceFactory registrations. The framework
> will only
> call your factory once as long as the use count of the service is
> greater
> than zero for a particular bundle. The framework will then cache
> that
> service instance and keep returning it directly to the bundle
> without
> calling the ServiceFactory again.
>
> Am I understanding your observation correctly? You are
> stating that your factory is not called multiple times for the
> same
> consuming bundle?
>
>
>
> I'm stating that when a single bundle is deployed which requests
> the same service multiple times the factory method is called
> multiple times
> and the bundle gets a different instance of the service each time.
>
> I'm not sure if there is some sort of race condition but the
> client bundle (in this case the felix webconsole) is requesting the
> HttpService mutliple times (in the same thread) and each time the
> equinox
> framework is invoking the HttpServiceFactory method returning
> different
> HttpServiceImpl instance.
>
> - Ray
>
>
>
> Tom
>
>
>
> [image: Inactive hide details for Raymond Auge ---04/28/2014
> 03:24:26 PM---Hey all, I have to write code as follows in a
> ServiceFactory]Raymond
> Auge ---04/28/2014 03:24:26 PM---Hey all, I have to write code as
> follows
> in a ServiceFactory impl in order for my
>
>
>
> From: Raymond Auge
> <*raymond.a...@liferay.com*<raymond.a...@liferay.com>
> >
> To: Equinox development mailing list <
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>>
> Date: 04/28/2014 03:24 PM
>
> Subject: [equinox-dev] bug or not
> Sent by:
> *equinox-dev-boun...@eclipse.org*<equinox-dev-boun...@eclipse.org>
>
>
> ------------------------------
>
>
>
> Hey all,
>
> I have to write code as follows in a ServiceFactory impl in
> order for my factory to always return the same instance per
> bundle running
> on equinox 3.8.0.v20120529-1548
>
> ===============================================
> public HttpService getService(
> Bundle bundle, ServiceRegistration<HttpService> registration)
> {
>
> HttpServiceImpl httpServiceImpl = serviceMap.get(bundle);
>
> if (httpServiceImpl != null) {
> return httpServiceImpl;
> }
>
> httpServiceImpl = new HttpServiceImpl(
> bundle, contextController, legacyServiceIdGenerator);
>
> serviceMap.putIfAbsent(bundle, httpServiceImpl);
>
> return httpServiceImpl;
> }
> ===============================================
>
> This seems clearly wrong as per the spec.
>
> It's certainly calling the getService method of the
> ServiceFactory which I'm guessing means it's not incorrectly
> registered.
>
> What could I be doing wrong? Was this ever a bug in equinox
> that was later resolved?
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay)
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
>
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list
> *equinox-dev@eclipse.org* <equinox-dev@eclipse.org>
> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
