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
