On Sun, Mar 8, 2015 at 3:11 PM, Balázs Zsoldos <balazs.zsol...@everit.biz> 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 | balazs.zsol...@everit.biz > > *EverIT Kft.* > 1137 Budapest, Katona József utca 17. III. em. 2. > http://www.everit.biz I i...@everit.biz > > > 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 <hargr...@us.ibm.com> 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/> >> *hargr...@us.ibm.com* <hargr...@us.ibm.com> >> >> office: +1 386 848 1781 >> mobile: +1 386 848 3788 >> >> >> >> >> >> From: Raymond Auge <raymond.a...@liferay.com> >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> Date: 2015/03/08 12:48 >> Subject: Re: [osgi-dev] getting a service filtered on my bundleId >> Sent by: osgi-dev-boun...@mail.osgi.org >> ------------------------------ >> >> >> >> 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 <*raymond.a...@liferay.com* >> <raymond.a...@liferay.com>> 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 <*raymond.a...@liferay.com* >> <raymond.a...@liferay.com>> 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 <*raymond.a...@liferay.com* >> <raymond.a...@liferay.com>> wrote: >> >> >> On Sun, Mar 8, 2015 at 11:58 AM, Neil Bartlett <*njbartl...@gmail.com* >> <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* >> <raymond.a...@liferay.com>> wrote: >> >> >> >> On Sun, Mar 8, 2015 at 11:18 AM, Tim Ward <*tim.w...@paremus.com* >> <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* >> <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* <osgi-dev@mail.osgi.org> >> *https://mail.osgi.org/mailman/listinfo/osgi-dev* >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> >> _______________________________________________ >> OSGi Developer Mail List >> *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> >> *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 >> *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> >> *https://mail.osgi.org/mailman/listinfo/osgi-dev* >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org> >> *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 >> 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 >> > > > _______________________________________________ > 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
