By new R6 service properties, I assume you mean service.bundleid which is the only one I see added in R6.
The answer is no for DS since DS is declarative and bundle id is assigned when the bundle is installed and unknown when the bundle is built. Although you can set the target via ConfigAdmin, that seems too complex. I am not sure why you need to use the bundle id anyway. The service provider should add some provider identifying property (fum.id=MyFum) to its service which the consumer can look for (target="(fum.id=MyFum)"). This way both parties know the identifier at build time and don't rely on something that varies in each installation. If the service provider is the Servlet Context from a WAB, use the osgi.web.symbolicname property as the provider identifying property. So the consumer can look for target="(osgi.web.symbolicname=my.bsn)". -- 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/09 11:25 Subject: Re: [osgi-dev] getting a service filtered on my bundleId Sent by: [email protected] Ok, let me ask a different way: Is there a way that I could use the new R6 service properties in target filters? On Mon, Mar 9, 2015 at 11:20 AM, Raymond Auge <[email protected]> wrote: On Mon, Mar 9, 2015 at 11:13 AM, BJ Hargrave <[email protected]> wrote: Why not: @Component(name="MyFum") public class MyFum implements Fum { } @Component public class MyFoo implements Foo { @Reference(target = "(component.name=MyFum)") public void setFum(Fum fum) {..} } What if Fum isn't 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/09 11:08 Subject: Re: [osgi-dev] getting a service filtered on my bundleId Sent by: [email protected] Allow me to demonstrate using a real world scenario we have right now. There is an API comprised of at least two parts - Foo & Fum There are many implementations of Foo and Fum coming from many bundles However, the typical case is also that a Foo impl uses it's own Fum impl. So, your first attempt looks like this: @Component(service = Fum.class) public class MyFum implements Fum { } @Component(service = Foo.class) public class MyFoo implements Foo { @Reference public void setFum(Fum fum) {..} } Now this can break, because there are many Fums, right? So I need to be more specific. At the moment I have to do an ugly hack which is export the Fum by also it's FumImpl type: @Component(service = {Fum.class, MuFum.class}) public class MyFum implements Fum { } and now in the Foo impl, I need to change to either: @Component(service = Foo.class) public class MyFoo implements Foo { @Reference(service = MyFum.class) public void setFum(Fum fum) {..} } OR @Component(service = Foo.class) public class MyFoo implements Foo { @Reference(target = "(objectClass=MyFum)") public void setFum(Fum fum) {..} } all of that is really crappy! Why do I need to expose the internal details just so I can connect two Components together with such crud information. Why can't I simply do this: @Component(service = Fum.class) public class MyFum implements Fum { } @Component(service = Foo.class) public class MyFoo implements Foo { @Reference(target = "(service.bundleid=${bundle.id})") public void setFum(Fum fum) {..} } There! problem solved! R6 added a few very nice service properties like service.bundleid but they are completely useless because I CAN'T use them realistically because that information is runtime only and you can't know about it ahead of time. On Mon, Mar 9, 2015 at 3:40 AM, Balázs Zsoldos <[email protected]> wrote: "we don't support multiple "active" extenders like DS" Even DS components use each-other via OSGi services and it does not (and should not) matter if those OSGi services are registered by components within the same bundle. In case all components are designed in the way that they know only about OSGi services, it should not be a problem to use Blueprint, DS, iPojo together within the same bundle. The problem starts when the components want to know about other components, not OSGi services. 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 8:37 PM, BJ Hargrave <[email protected]> wrote: > From: Raymond Auge <[email protected]> > BJ bundles are not limited to using only a single spec! OSGi is > modular after all, no? > It's entirely possible for a bundle to use several extenders at > once. This is a completely legitimate use case. > This is exactly the case I'm dealing with. > I don't think what I'm asking is outlandish. It is a case discussed in the OSGi EGs and that we never agreed to solve. Basically, we don't support multiple "active" extenders like DS, Blueprint and Web Application Specification each trying to control a bundle. There is no way to coordinate that as you see. We certainly expect different bundles to use different technologies, but did not do anything to support a single bundle to be extended by multiple active extenders. What you are attempting to do is outside the scope of the existing OSGi specifications. I highly recommend you split the bundle up so that only a single active extender is controlling each bundle. -- 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 _______________________________________________ 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) _______________________________________________ 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
