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,
>
Am 09.03.15 um 16:10 schrieb Raymond Auge:
> In fact, I would be satisfied it there were placeholders ONLY for the
> service properties which can only be known at runtime.
>
Thanks Ray, I understand your use case now.
You have to somehow - at runtime - provide your mapping, so for all your
Foo im
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?
tha
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
wrote:
> Allow me to demonstrate using a real world scenario we have right now.
>
> There is an API comprised of at least two
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 atte
Am 09.03.15 um 15:51 schrieb Raymond Auge:
> On Mon, Mar 9, 2015 at 10:48 AM, Felix Meschberger
> wrote:
>
>> Hi
>>
>> What prevents you from doing this with your build tooling ? This should,
>> apart from the bundle.id part, be rather easy.
>>
>
> You can't see runtime info from the build!
>
>
On Mon, Mar 9, 2015 at 10:48 AM, Felix Meschberger
wrote:
> Hi
>
> What prevents you from doing this with your build tooling ? This should,
> apart from the bundle.id part, be rather easy.
>
You can't see runtime info from the build!
This is the main point!
>
> E.g. leveraging the resource fi
On Mon, Mar 9, 2015 at 10:29 AM, Carsten Ziegeler
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
Hi
What prevents you from doing this with your build tooling ? This should, apart
from the bundle.id part, be rather easy.
E.g. leveraging the resource filtering feature of Maven
Regards
Felix
> Am 09.03.2015 um 15:08 schrieb Raymond Auge :
>
> On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler
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 configu
On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler
wrote:
> Am 08.03.15 um 16:24 schrieb Raymond Auge:
> > Would people be opposed to felix scr supporting property replacement
> > something like (à la spring PropertyPlaceholderConfigurer):
> >
> > // implied from bundle runtime details
> > @Referen
Am 08.03.15 um 16:24 schrieb Raymond Auge:
> Would people be opposed to felix scr supporting property replacement
> something like (à la spring PropertyPlaceholderConfigurer):
>
> // implied from bundle runtime details
> @Reference(target = "(service.bundleid=${bundle.id})")
>
> // implied from b
Would people be opposed to felix scr supporting property replacement
something like (à la spring PropertyPlaceholderConfigurer):
// implied from bundle runtime details
@Reference(target = "(service.bundleid=${bundle.id})")
// implied from bundle headers
@Reference(target = "(context.path=${Web-Co
13 matches
Mail list logo
