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! To be honest this doesn’t sound like a job for the service registry, but instead Java’s “new” keyword… 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] > <mailto:[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] > <mailto:[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] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > _______________________________________________ > OSGi Developer Mail List > [email protected] <mailto:[email protected]> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <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
