Raymond, I agree with Carsten, you can use ConfigurationAdmin to ensure that a target service is properly wired.
In my case all components instances are being created by my central service. So, all components requires a configuration instance in order to be activated. @Component(enabled = true, > configurationPid = Constants.BSDS_PID, > configurationPolicy = ConfigurationPolicy.REQUIRE) > and then I set the target using this syntax: InterfaceFactoryForTesting.target=(p.color=blue) > 2015-03-09 12:07 GMT-03:00 Raymond Auge <[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 10:51 AM, Raymond Auge <[email protected]> > wrote: > > > > > > > On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler <[email protected]> > > wrote: > > > >> Am 09.03.15 um 15:08 schrieb Raymond Auge: > >> > >> > > >> > This also isn't the goal. The goal is to automate/simplify parts which > >> you > >> > don't want to handle via configuration. For instance you would never > use > >> > the bundle.id because that would be foolish since uninstall and > >> reinstall > >> > would make the configuration invalid. > >> > > >> > However, there are many details for which it might be useful to be > able > >> to > >> > apply filters on, but due to their dynamic nature its impractical to > use > >> > them because you must hard code the values currently. This is true for > >> > almost all details of a bundle at runtime. > >> > > >> > It's also true that some information you don't want to duplicate. For > >> > instance, anything that is in the manifest you probably want to keep > >> > centralized there, and not require a developer to duplicate it since > >> this > >> > causes a change management problem. > >> > > >> > So, my thought about where the information for replacement is that it > >> would > >> > come from only > >> > - bundle runtime info > >> > >> What exactly do you mean with that? > >> > >> > - manifest > >> > >> How is this different from a properties file in the bundle? > >> > > > > It's most often calculated during the build and you can't really see the > > result until the bundle is running. > > > > > >> > >> Regards > >> Carsten > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> [email protected] > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > *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) > -- "Tudo vale a pena se a alma não é pequena..."
