You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Bengt Rodehav <be...@rodehav.com> on 2021/09/07 08:39:00 UTC
iPojo Controller
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
Re: iPojo Controller
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <tj...@gmail.com>:
> 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 <be...@rodehav.com> 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 <ka...@gmail.com>:
> >
> > > 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 <be...@rodehav.com>
> 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
> > > karlpauls@gmail.com
> > >
> >
>
Re: iPojo Controller
Posted by Karl Pauls <ka...@gmail.com>.
On Tue, Sep 7, 2021 at 5:36 PM David Jencks <da...@gmail.com> 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 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.
Yes, the condition spec is basically that idea just made a little easier.
regards,
Karl
> David Jencks
>
> > On Sep 7, 2021, at 6:02 AM, Thomas Watson <tj...@gmail.com> 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 <be...@rodehav.com> 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 <ka...@gmail.com>:
> >>
> >>> 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 <be...@rodehav.com> 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
> >>> karlpauls@gmail.com
> >>>
> >>
>
--
Karl Pauls
karlpauls@gmail.com
Re: iPojo Controller
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>:
> 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 <david.a.jencks@gmail.com
> >:
>
>> 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 <tj...@gmail.com> 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 <be...@rodehav.com> 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 <ka...@gmail.com>:
>> >>
>> >>> 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 <be...@rodehav.com>
>> 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
>> >>> karlpauls@gmail.com
>> >>>
>> >>
>>
>>
Re: iPojo Controller
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <da...@gmail.com>:
> 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 <tj...@gmail.com> 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 <be...@rodehav.com> 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 <ka...@gmail.com>:
> >>
> >>> 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 <be...@rodehav.com>
> 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
> >>> karlpauls@gmail.com
> >>>
> >>
>
>
Re: iPojo Controller
Posted by David Jencks <da...@gmail.com>.
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 <tj...@gmail.com> 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 <be...@rodehav.com> 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 <ka...@gmail.com>:
>>
>>> 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 <be...@rodehav.com> 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
>>> karlpauls@gmail.com
>>>
>>
Re: iPojo Controller
Posted by Thomas Watson <tj...@gmail.com>.
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 <be...@rodehav.com> 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 <ka...@gmail.com>:
>
> > 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 <be...@rodehav.com> 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
> > karlpauls@gmail.com
> >
>
Re: iPojo Controller
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <ka...@gmail.com>:
> 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 <be...@rodehav.com> 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
> karlpauls@gmail.com
>
Re: iPojo Controller
Posted by Karl Pauls <ka...@gmail.com>.
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 <be...@rodehav.com> 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
karlpauls@gmail.com