So the MyFum service might be used by other bundles too, but MyFoo will always only use MyFum, not any Fum implementations from other bundles? Why even use the service registry at all when MyFoo fetches its implementation of a Fum? If it will only *ever* use MyFum then that's another way of saying it is conceptually tightly coupled to that specific implementation, so the service registry seems the wrong tool to use to fetch a reference... Honestly, the 'really crap' way you outlined makes just as much sense to me than what you're asking for...
On 9 March 2015 at 15:10, Raymond Auge <[email protected]> wrote: > In fact, I would be satisfied it there were placeholders ONLY for the > service properties which can only be known at runtime. > > On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge <[email protected]> > wrote: > >> 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* <http://www.osgi.org/> >>>> *[email protected]* <[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é* <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
