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)
