I was just going with the examples you were using. You could also just use
non-DS defined property names. Then the service could be registered in
some other way.
@Component(property="fum.id=MyFum")
public class MyFum implements Fum { }
@Component
public class MyFoo implements Foo {
@Reference(target = "(fum.id=MyFum)")
public void setFum(Fum fum) {..}
}
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 2015/03/09 11:22
Subject: Re: [osgi-dev] getting a service filtered on my bundleId
Sent by: [email protected]
On Mon, Mar 9, 2015 at 11:13 AM, BJ Hargrave <[email protected]> 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
[email protected]
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Raymond Auge <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 2015/03/09 11:08
Subject: Re: [osgi-dev] getting a service filtered on my bundleId
Sent by: [email protected]
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
[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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
_______________________________________________
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
