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)
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
