On Sun, Mar 8, 2015 at 2:25 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:
> DS adds a component.name property to each component's properties. You > control the component name. So you can find a service with the > component.name you control. > Sheesh.. the thing I want to "get" is NOT a component! > -- > > *BJ Hargrave* > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> > *hargr...@us.ibm.com* <hargr...@us.ibm.com> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > From: Raymond Auge <raymond.a...@liferay.com> > To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Date: 2015/03/08 12:48 > Subject: Re: [osgi-dev] getting a service filtered on my bundleId > Sent by: osgi-dev-boun...@mail.osgi.org > ------------------------------ > > > > I come up with: > > @Activate > protected void activate(BundleContext bundleContext) { > Bundle bundle = bundleContext.getBundle(); > > _bundleId = bundle.getBundleId(); > } > > @Reference( > cardinality = ReferenceCardinality.AT_LEAST_ONE, > policy = ReferencePolicy.DYNAMIC, > policyOption = ReferencePolicyOption.GREEDY > ) > protected void setServletContext( > ServletContext servletContext, Map<String, Object> properties) { > > long serviceBundleId = MapUtil.getLong(properties, > "service.bundleid"); > > if (serviceBundleId == _bundleId) { > _servletContext = servletContext; > } > } > > private long _bundleId; > private volatile ServletContext _servletContext; > > Man that's ugly! > I think I prefer: > > @Activate > protected void activate(BundleContext bundleContext) > throws InvalidSyntaxException { > > Bundle bundle = bundleContext.getBundle(); > > Filter filter = bundleContext.createFilter( > "(&(objectClass=" + ServletContext.class.getName() + > ")(service.bundleid=" + bundle.getBundleId() + "))"); > > _serviceTracker = new ServiceTracker<ServletContext, > ServletContext>( > bundleContext, filter, null); > > _serviceTracker.open(); > } > > @Deactivate > protected void deactivate() { > _serviceTracker.close(); > } > > private ServiceTracker<ServletContext, ServletContext> _serviceTracker; > > But I really wish I could do: > > @Reference(target = "(service.bundleid=${*bundle.id* > <http://bundle.id/>})") > protected void setServletContext(ServletContext servletContext) { > _servletContext = servletContext; > } > > private volatile ServletContext _servletContext; > > > > On Sun, Mar 8, 2015 at 12:17 PM, Raymond Auge <*raymond.a...@liferay.com* > <raymond.a...@liferay.com>> wrote: > .. pray there isn't multi version, or mutli-instance support for this type > of extender. > > On Sun, Mar 8, 2015 at 12:08 PM, Raymond Auge <*raymond.a...@liferay.com* > <raymond.a...@liferay.com>> wrote: > Tim and Neil, > > Are you both suggesting that it's better to do the following? > > The manifest file contains: > > Web-ContextPath: /blah > > > The component contains: > > @Reference(target = "(osgi.web.contextpath=/blah)") > protected void setServletContext(ServletContext servletContext) { ... } > > > On Sun, Mar 8, 2015 at 12:02 PM, Raymond Auge <*raymond.a...@liferay.com* > <raymond.a...@liferay.com>> wrote: > > > On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <*njbartl...@gmail.com* > <njbartl...@gmail.com>> wrote: > Ray, to quote two sentences from your email: > > * "I want the thing that was built for me specifically” > * "I never talked about coupling providers to consumers.” > > These two statements are in direct contradiction with each other! > > If there is coupling, it's coupling I specifically want, and it lives > inside my bundle! So what's the issue? > > > To be honest this doesn’t sound like a job for the service registry, but > instead Java’s “new” keyword… > > You've missed the point! It's someone else who already created the thing I > need! However, it still belongs to me! > > Please see my examples. > > > Neil > > > On 8 Mar 2015, at 15:38, Raymond Auge <*raymond.a...@liferay.com* > <raymond.a...@liferay.com>> wrote: > > > > On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <*tim.w...@paremus.com* > <tim.w...@paremus.com>> wrote: > Hi Ray, > > Using the bundle id feels more like a workaround for a missing feature of > the extender. > > Wouldn't it make more sense for the metadata processed by the extender > publish a property to filter on, and/or to have the service published by > the extender respond to config admin in the same way that DS components do? > > If, for example, the extendee asked for the property > "mySuperCoolProperty=awesome" to be applied to the extender registered > service then that could be used in the filter. > > that won't work because neither do you know the value of the property at > build time, nor in this case do you want to change the value during > configuration. I want the thing that was built for me specifically... the > only unique value that I know about is bundleId. > > Ideally the target filter would be set using config admin to maximise the > reusability of the bundle (for example in an environment without the > extender where another service should be used). > > Config admin implies human responsibility and in this case I don't want > humans involved. > > I can create a contrived example of this using current OSGi pieces. > > I have a bundle, it uses both gemini blueprint and DS. > > How can I tell the DS component to get my instance of > org.springframework.context.ConfigurableApplicationContext? I can't without > manually implementing a ServiceTracker because the only bits I can filter > on are things you can't know at XML creation time or that you'd never want > to duplicate from the manifest. > > > > One of the best things about the service registry is decoupling the > provider from the consumer. I'd try very hard to avoid breaking that. > > I never talked about coupling providers to consumers. > > > Regards, > > Tim > > > > Sent from my iPhone > > On 8 Mar 2015, at 14:49, Raymond Auge <*raymond.a...@liferay.com* > <raymond.a...@liferay.com>> wrote: > > Hey all, > > I have a need for a component to get a service created on behalf of the > bundle by an extender. There are many such services in the system so what I > really need is to get a bundle with a filter like so: > > Filter filter = bundleContext.createFilter( > "(&(objectClass=" + ExtenderCreatedService.class.getName() + > ")(service.bundleid=" + bundle.getBundleId() + "))"); > > i.e. get the one created which has my bundleId. > > Is there any trick to doing this besides a ServiceTracker which the > component must manually create and start? > > Note the component can't know it's own bundleId at the time of generating > the XML. > > Is there any property parsing happening in the component XML files or > anything? > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> > *https://mail.osgi.org/mailman/listinfo/osgi-dev* > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance) > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance) > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance) > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com/> > (@Liferay) > Board Member & EEG Co-Chair, *OSGi Alliance* <http://osgi.org/> > (@OSGiAlliance)_______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
