Wow Ray, you give up easy :-)
Kind regards,
Peter Kriens
> On 9 mrt. 2015, at 16:56, Raymond Auge <raymond.a...@liferay.com> wrote:
>
> Thanks all!
>
> - Ray
>
> On Mon, Mar 9, 2015 at 11:53 AM, BJ Hargrave <hargr...@us.ibm.com
> <mailto:hargr...@us.ibm.com>> wrote:
> By new R6 service properties, I assume you mean service.bundleid which is the
> only one I see added in R6.
>
> The answer is no for DS since DS is declarative and bundle id is assigned
> when the bundle is installed and unknown when the bundle is built. Although
> you can set the target via ConfigAdmin, that seems too complex.
>
> I am not sure why you need to use the bundle id anyway. The service provider
> should add some provider identifying property (fum.id <http://fum.id/>=MyFum)
> to its service which the consumer can look for (target="(fum.id
> <http://fum.id/>=MyFum)"). This way both parties know the identifier at build
> time and don't rely on something that varies in each installation.
>
> If the service provider is the Servlet Context from a WAB, use the
> osgi.web.symbolicname property as the provider identifying property. So the
> consumer can look for target="(osgi.web.symbolicname=my.bsn)".
> --
>
> 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>
>
>
>
>
> From: Raymond Auge <raymond.a...@liferay.com
> <mailto:raymond.a...@liferay.com>>
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org
> <mailto:osgi-dev@mail.osgi.org>>
> Date: 2015/03/09 11:25
> Subject: Re: [osgi-dev] getting a service filtered on my bundleId
> Sent by: osgi-dev-boun...@mail.osgi.org
> <mailto:osgi-dev-boun...@mail.osgi.org>
>
>
>
> 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
> <mailto:raymond.a...@liferay.com>> wrote:
>
>
> On Mon, Mar 9, 2015 at 11:13 AM, BJ Hargrave <hargr...@us.ibm.com
> <mailto: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 <http://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 <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>
>
>
>
>
> From: Raymond Auge <raymond.a...@liferay.com
> <mailto:raymond.a...@liferay.com>>
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org
> <mailto: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
> <mailto: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
> <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 <tel:%2B36%2070%20594%209234> | 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
> <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
> <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 <mailto: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 <mailto: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)
>
>
>
> --
> 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
> <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
> <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
