Some real life example about such two extenders would be really great. Probably I am missing something. I am not sure I can come up with any example (except if the example is related to OSGi unfriendly technologies like JPA)
On Sun, Mar 8, 2015 at 8:15 PM, Raymond Auge <[email protected]> wrote: > > > On Sun, Mar 8, 2015 at 3:11 PM, Balázs Zsoldos <[email protected]> > wrote: > >> @BJ: component.name worked for Ray only if bundle id was part of the >> component and the component was singleton. >> >> @All, who wants a feature like expressions in reference configuration: >> >> If dynamic parts were supported in reference filters, an expression >> evaluator technology should be introduced. That is an overhead in memory >> and startup time. Are you sure it is worth it? >> >> You need these expressions to be able to build up additional solutions >> based on WABs. Probably the issue is with the concept of WAB. That is based >> on WARs that were not designed to work within OSGi. The reason you need >> workarounds like this is that you try using OSGi and a monoholitic solution >> together. >> > > > WAB just happens to be one example! However, I did demonstrate with > another example which was not WAB. > > The case would be the same whenever there are two extenders in one bundle. > > If you want the services created by these two extenders to collaborate, > without writing a lot of boiler plate code, there is no way. > > Sincerely, > - Ray > > >> >> In the past popular monoholitic technologies had to be bridged into OSGi >> to let OSGi live in server environments. That compromise had to be made at >> that time and we should feel really thankful for the ones who put enough >> energy to specify and implement them. As OSGi is getting more popular >> nowadays, probably someone with enough reputation should clarify that these >> technologies will *never* work even if many workarounds (bridges and >> features) are provided. >> >> >> >> *Zsoldos Balázs* >> Rendszertervező | Software architect >> >> >> +36 70 594 9234 | [email protected] >> >> *EverIT Kft.* >> 1137 Budapest, Katona József utca 17. III. em. 2. >> http://www.everit.biz I [email protected] >> >> >> Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt >> áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve >> az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet >> címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az >> üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt >> mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben >> tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia, >> elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie. >> >> >> This message and any attachment are confidential and are legally >> privileged. It is intended solely for the use of the individual or entity >> to whom it is addressed and others authorised to receive it. If you are not >> the intended recipient, please telephone or email the sender and delete >> this message and any attachment from your system. Please note that any >> dissemination, distribution, copying or use of or reliance upon the >> information contained in and transmitted with this e-mail by or to anyone >> other than the recipient designated above by the sender is unauthorised and >> strictly prohibited. >> >> On Sun, Mar 8, 2015 at 7: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. >>> -- >>> >>> *BJ Hargrave* >>> Senior Technical Staff Member, IBM >>> OSGi Fellow and CTO of the *OSGi Alliance* <http://www.osgi.org/> >>> *[email protected]* <[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* >>> <http://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]* <[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]* <[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]* <[email protected]>> wrote: >>> >>> >>> On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <*[email protected]* >>> <[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]* >>> <[email protected]>> wrote: >>> >>> >>> >>> On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <*[email protected]* >>> <[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]* >>> <[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]* <[email protected]> >>> *https://mail.osgi.org/mailman/listinfo/osgi-dev* >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> *[email protected]* <[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]* <[email protected]> >>> *https://mail.osgi.org/mailman/listinfo/osgi-dev* >>> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> *[email protected]* <[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) >>> >>> >>> >>> -- >>> *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 >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> _______________________________________________ >>> 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é* <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
