Karl,
I have been reading the Condition specification that you referenced to me.
Looks interesting but I'm not sure how I could use it to solve my problem.
Today, all our services have the following boiler plate code (using iPojo):
@Controller
@Property(name = "service.enabled&q
David,
Yes controlling by adding and removing configurations (with factories) is
possible with other means than iPojo. However, we have a system where we
manage the configurations (they are present all the time) but start/stop
them by setting an "enabled" (configuration property) to true/false. It
OK - thanks for the info. I'll keep a watch on these things.
/Bengt
Den tis 7 sep. 2021 kl 15:03 skrev Thomas Watson :
> The condition specification is part of OSGi R8 Core and Compendium
> releases. The OSGi R8 Core (Framework) implementation is available now
> with implementations available f
On Tue, Sep 7, 2021 at 5:36 PM David Jencks wrote:
>
> I haven’t looked at the condition spec nor IPOJO’s @Controller, but for many
> years you’ve been able to influence the presence of DS component instances
> through configuration by making the component configuration-required and only
> supp
I haven’t looked at the condition spec nor IPOJO’s @Controller, but for many
years you’ve been able to influence the presence of DS component instances
through configuration by making the component configuration-required and only
supplying configurations for the instances you want.
I seem to re
The condition specification is part of OSGi R8 Core and Compendium
releases. The OSGi R8 Core (Framework) implementation is available now
with implementations available from Felix and Equinox. The
condition factory specification is in the works but is not going to be
included with the OSGI R8 spe
Thanks Karl for your tip.
Do you know which version of DS/SCR is required for using the new condition
specification? Is it included in Karaf?
Unfortunately I don't have the possibility to help develop iPojo. I've
helped out in a few projects before but I think iPojo is a bit over my head
both in
Hi,
I agree that iPojo is a very good component model and it will be hard
to replace it. I think the closest you could come to replace it with
would be a combination of Declarative Services (DS/SCR) and the new
condition specification [0] - obviously depends on what you where
actually doing with i
I have noticed that iPojo is not supported any more. That is unfortunate
for us since we have built a lot of our functionality on iPojo. It's
actually the best component model I have seen so far.
We need to move on to something else then. What would you suggest? What
alternative is closest to iPoj
