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 recall also controlling whether instances are created by having a mandatory reference and adjusting the target filter in configuration so it is or isn’t satisfied. David Jencks > On Sep 7, 2021, at 6:02 AM, Thomas Watson <[email protected]> wrote: > > 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 specifications ( > https://github.com/osgi/osgi/blob/design/168/.design/design-168.md). But > the declarative services specification for OSGi R8 has been updated to > include how conditions can influence service components. A release > candidate of Felix SCR 2.2.0-RC1 will be available shortly that implements > the latest OSGi R8 release candidate APIs. The final release of OSGi R8 > compendium will hopefully be released by October. All of that means that > it is not available in Karaf at this time. > > Tom > > On Tue, Sep 7, 2021 at 6:14 AM Bengt Rodehav <[email protected]> wrote: > >> 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 skills and time. >> >> Best regards, >> >> Bengt >> >> Den tis 7 sep. 2021 kl 11:10 skrev Karl Pauls <[email protected]>: >> >>> 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 iPojo (for a simple @Controller it might be enough >>> to use conditions). >>> >>> That said, let me point out: there is no reason iPojo couldn't still >>> be developed - we just lack somebody to work on it for the time being. >>> If you (and/or others you know) want to continue to develop it that >>> certainly could be a way forward as well. >>> >>> regards, >>> >>> Karl >>> >>> >>> [0] >>> >> http://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html#service.condition >>> >>> >>> On Tue, Sep 7, 2021 at 10:39 AM Bengt Rodehav <[email protected]> wrote: >>>> >>>> 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 iPojo in functionality? >>>> >>>> The big difference for us has been the @Controller annotation. With >> this >>> we >>>> have a system where we enable/disable services using configurations. I >>>> really need some way to achieve the same but with another model than >>> iPojo. >>>> I would appreciate any suggestions. >>>> >>>> /Bengt >>> >>> >>> >>> -- >>> Karl Pauls >>> [email protected] >>> >>
