The issue I see is a bundle interacting indirectly with parts that were created by an extender on the bundle's behalf. In these cases you really don't want to require configuration, you also don't know the info ahead of time. AND if at all possible you want to avoid as much boiler plate code as possible.
Right now I have to write the exact same code in every bundle that's being extended OR I have to write some ugly class to share the logic... which to me a far worse coupling. - Ray On Sun, Mar 8, 2015 at 11:47 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > Another contrived but legit scenario: > > I have a WAB and the WAB includes DS components. > > The WAB spec says to publish a service for the ServletContext. > > How do I get "my" ServletContext in my DS component? > > The only way again is to implement a ServiceTracker filtering on things I > can't know ahead of time. > > - Ray > > On Sun, Mar 8, 2015 at 11:38 AM, 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) >> > > > > -- > *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
