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> wrote: > > > On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <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> wrote: >> >> >> >> On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <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> 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 >>> 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 >> >> >> >> _______________________________________________ >> 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) > -- *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