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", mandatory = true) private boolean mValid; A typical service could be a Camel route activated using factory configuration, meaning that the existence of a configuration will trigger creating the component. We can then enable the component by setting the "service.enabled" property to true and disable (stop) it by setting this property to false. It is very convenient and the configuration can be altered in several ways: By updating the configuration file, via the web console (in Karaf) or via our custom made web GUI. >From what I can see, the Condition specification only talks about service dependencies - not configuration properties. Do you think the Condition service could still be used for depending on a configuration property? /Bengt Den ons 8 sep. 2021 kl 10:42 skrev Bengt Rodehav <[email protected]>: > 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 is > a lot more user friendly (and dynamic) than having to remove the > configuration completely. It would take a lot of effort for us to change > this pattern since we've built a lot of functionality around it. > > /Bengt > > Den tis 7 sep. 2021 kl 17:36 skrev David Jencks <[email protected] > >: > >> 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] >> >>> >> >> >> >>
