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 <raymond.a...@liferay.com>
wrote:
>
>
> On Mon, Mar 9, 2015 at 11:13 AM, BJ Hargrave <hargr...@us.ibm.com> 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* <http://www.osgi.org/>
>> *hargr...@us.ibm.com* <hargr...@us.ibm.com>
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>>
>>
>>
>> From: Raymond Auge <raymond.a...@liferay.com>
>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
>> Date: 2015/03/09 11:08
>> Subject: Re: [osgi-dev] getting a service filtered on my bundleId
>> Sent by: osgi-dev-boun...@mail.osgi.org
>> ------------------------------
>>
>>
>>
>> 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* <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* <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*
>> <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*
>> <hargr...@us.ibm.com>> wrote:
>> > From: Raymond Auge <*raymond.a...@liferay.com*
>> <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* <%2B1%20386%20848%201781>
>> mobile: *+1 386 848 3788* <%2B1%20386%20848%203788>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>
>> *https://mail.osgi.org/mailman/listinfo/osgi-dev*
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> *osgi-dev@mail.osgi.org* <osgi-dev@mail.osgi.org>
>> *https://mail.osgi.org/mailman/listinfo/osgi-dev*
>> <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
>> 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
