On Sun, Mar 8, 2015 at 11:53 AM, Raymond Auge <raymond.a...@liferay.com> wrote:
> The issue I see is a bundle interacting indirectly > I meant "directly" not "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) > -- *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
