Hey all,
I think I may have gotten a false positive on some tests because this week
I can't reproduce it.
Seems you should test code again after a week off. Glad I didn't file a
ticket.
Excuse the noise,
Ray
On Apr 28, 2014 9:07 PM, "Richard Hall" <he...@ungoverned.org> wrote:
> 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> 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>
>> To: Equinox development mailing list <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
>> ------------------------------
>>
>>
>>
>> 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
>> 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
