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>
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 <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
>>
>> *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 8:37 PM, BJ Hargrave <hargr...@us.ibm.com> wrote:
>>
>>> > From: Raymond Auge <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* <hargr...@us.ibm.com>
>>>
>>> office: +1 386 848 1781
>>> mobile: +1 386 848 3788
>>>
>>>
>>> _______________________________________________
>>> 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)
>
--
*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
