I think you have prematurely decided on a solution and have not analyzed your requirements from a sufficiently abstract level.
There are a ton of ways to specify wiring that don't augment the ds spec. From a more conceptual level, what is determining which Fum a particular Foo is wired to? thanks david jencks On Mar 9, 2015, at 11:10 AM, Raymond Auge <[email protected]> wrote: > In fact, I would be satisfied it there were placeholders ONLY for the > service properties which can only be known at runtime. > > On Mon, Mar 9, 2015 at 11:07 AM, Raymond Auge <[email protected]> > wrote: > >> 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) >> > > > > -- > *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) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
