This is a gift! :-) It means your code is not handling the dynamics correctly
and now you know it!
The cause is that that the DS starts the components before the Configurator has
done its work. The easiest solution seems to be to use start levels. If your
code CAN handle the dynamics, then this is one of the few legitimate places
where startlevels are useful. I usually oppose it because people do not handle
the dynamics correctly and want a short cut. This is fine until it is not. And
the ‘not’ happens guaranteed one day. So first fix the dynamics, and then think
of solutions that improve the experience.
For this purpose, enRoute Classic had a
‘osgi.enroute.configurer.api.ConfigurationDone’ service. If you made an
@Reference to ConfigurationDone then you were guaranteed to not start before
the Configurer had done its magic. Since you did not want to depend on such a
specific service for reasons of cohesion, I developed AggregateState. One of
the aggregated states was then the presence of the ConfigurationDone service.
Although this is also not perfectly cohesive it at least aggregates all the
uncohesive things in one place and it is configurable.
Although this works the customer still is not completely happy since also the
Aggregate State feels uncohesive. So we’ve been discussing a new angle. I want
to try to make the Configuration Records _transient_. In Felix Config Admin you
can provide a persistence service (and it was recently made useful). I was
thinking of setting a special property in the configuration (something like
‘:persistence:transient’). The persistence layer would then _not_ persist it.
I.e. after a restart there would be no configuration until the Configurer sets
it. This will (I expect) seriously diminish the bouncing caused for these kind
of components.
And if you’re asking why I am still on the enRoute classic Configurer. Well, it
has ‘precious’ fields and they solved a nasty problem. We needed to use a well
defined value but if the user set one of those values, we wanted to keep the
user’s value. Quite a common scenario. With `precious` fields you rely on
default values (so no value for a precious field in the configurer’s input) but
copy the previous value to the newer configuration, if present. Works quite
well.
I think `transient` and `precious` could be nice extensions to the new
Configurator for R8.
Hope this helps. Kind regards,
Peter Kriens
> On 12 Jul 2018, at 00:48, David Leangen via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
>
> Hi!
>
> A question about component configuration.
>
> I have a component that has a required configuration policy. Using a (pre R7)
> Configurator to configure the component. For some reason, the Component gets
> activated, deactivated, then activated again, which is not desirable.
>
> Questions:
>
> 1. How can I figure out why this is happening. I have tried many approaches,
> but can’t seem to get a clue as to why this is happening. Since it generally
> doesn’t seem to happen for other configured components, I am assuming that it
> is not a Configurator problem.
>
> 2. Is there a way to prohibit this from happening?
>
>
> In the meantime, I will make the dependent services more dynamic so they are
> not thrown off by this change, but their behavior is actually correct: the
> expectation is that the configured service should only get instantiated once,
> so a static @Reference is correct.
>
>
> Thanks!
> =David
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
