.. 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 <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <[email protected]> >> 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 <[email protected]> wrote: >>> >>> >>> >>> On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> 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)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
