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 <raymond.a...@liferay.com>
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 <raymond.a...@liferay.com>
> wrote:
>
>>
>>
>> On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler <cziege...@apache.org>
>> 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
>>> cziege...@apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>>
>>
>> --
>> *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)
