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" <[email protected]> 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" <[email protected]> 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" <[email protected]> >> To: Equinox development mailing list <[email protected]> >> Date: 04/28/2014 05:34 PM >> Subject: Re: [equinox-dev] bug or not >> Sent by: [email protected] >> ------------------------------ >> >> >> >> 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 *<[email protected]>*<[email protected]> >> To: Equinox development mailing list >> *<[email protected]>*<[email protected]> >> Date: 04/28/2014 04:26 PM >> Subject: Re: [equinox-dev] bug or not >> Sent by: >> *[email protected]*<[email protected]> >> >> ------------------------------ >> >> >> >> 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 < >> *[email protected]* <[email protected]>> wrote: >> >> >> >> On Mon, Apr 28, 2014 at 5:17 PM, Thomas Watson < >> *[email protected]* <[email protected]>> 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 >> <*[email protected]*<[email protected]> >> > >> To: Equinox development mailing list >> <*[email protected]*<[email protected]> >> > >> Date: 04/28/2014 03:24 PM >> >> Subject: [equinox-dev] bug or not >> Sent by: >> *[email protected]*<[email protected]> >> >> ------------------------------ >> >> >> >> 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 >> *[email protected]* <[email protected]> >> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> >> >> _______________________________________________ >> equinox-dev mailing list >> *[email protected]* <[email protected]> >> *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 >> *[email protected]* <[email protected]> >> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> >> >> >> _______________________________________________ >> equinox-dev mailing list >> *[email protected]* <[email protected]> >> >> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > >
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
