I am sorry. Your example used DS and you want to get a service from the same bundle. I assumed that service would also be a component which I think was a reasonable assumption. Do you have a bundle that is both extended by DS and by some other extender which registers the other service?
> I have a bundle, it uses both gemini blueprint and DS. I went back and saw that. Good luck and godspeed! -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2015/03/08 14:55 Subject: Re: [osgi-dev] getting a service filtered on my bundleId Sent by: [email protected] On Sun, Mar 8, 2015 at 2:25 PM, BJ Hargrave <[email protected]> wrote: DS adds a component.name property to each component's properties. You control the component name. So you can find a service with the component.name you control. Sheesh.. the thing I want to "get" is NOT a component! -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2015/03/08 12:48 Subject: Re: [osgi-dev] getting a service filtered on my bundleId Sent by: [email protected] I come up with: @Activate protected void activate(BundleContext bundleContext) { Bundle bundle = bundleContext.getBundle(); _bundleId = bundle.getBundleId(); } @Reference( cardinality = ReferenceCardinality.AT_LEAST_ONE, policy = ReferencePolicy.DYNAMIC, policyOption = ReferencePolicyOption.GREEDY ) protected void setServletContext( ServletContext servletContext, Map<String, Object> properties) { long serviceBundleId = MapUtil.getLong(properties, "service.bundleid"); if (serviceBundleId == _bundleId) { _servletContext = servletContext; } } private long _bundleId; private volatile ServletContext _servletContext; Man that's ugly! I think I prefer: @Activate protected void activate(BundleContext bundleContext) throws InvalidSyntaxException { Bundle bundle = bundleContext.getBundle(); Filter filter = bundleContext.createFilter( "(&(objectClass=" + ServletContext.class.getName() + ")(service.bundleid=" + bundle.getBundleId() + "))"); _serviceTracker = new ServiceTracker<ServletContext, ServletContext>( bundleContext, filter, null); _serviceTracker.open(); } @Deactivate protected void deactivate() { _serviceTracker.close(); } private ServiceTracker<ServletContext, ServletContext> _serviceTracker; But I really wish I could do: @Reference(target = "(service.bundleid=${bundle.id})") protected void setServletContext(ServletContext servletContext) { _servletContext = servletContext; } private volatile ServletContext _servletContext; On Sun, Mar 8, 2015 at 12:17 PM, Raymond Auge <[email protected]> wrote: .. 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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance (@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
