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