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)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
