On 3/9/15 11:29 , elias vasylenko wrote:
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...
I was going to write the same thing myself...thanks for saving me the effort. :-)
-> richard
On 9 March 2015 at 15:10, Raymond Auge <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>> 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 <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>> 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 <http://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 <balazs.zsol...@everit.biz <mailto:balazs.zsol...@everit.biz>> 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 | balazs.zsol...@everit.biz <mailto:balazs.zsol...@everit.biz> * * *EverIT Kft.* 1137 Budapest, Katona József utca 17. III. em. 2. http://www.everit.biz <http://www.everit.biz/> I i...@everit.biz <mailto: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 8:37 PM, BJ Hargrave <hargr...@us.ibm.com <mailto:hargr...@us.ibm.com>> wrote: > From: Raymond Auge <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>> > 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/>_ __hargr...@us.ibm.com_ <mailto:hargr...@us.ibm.com> office: +1 386 848 1781 <tel:%2B1%20386%20848%201781> mobile: +1 386 848 3788 <tel:%2B1%20386%20848%203788> _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org <mailto: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)-- *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 <mailto: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
