Well, OSGi has a tendency to punish short cuts. In the long run this is very
valuable, I’ve seen too many software disasters to sleep well at night.
However, for a developer behind his screen and a looming deadline the long term
goals are unfortunately not so urgent :-(
Kind regards,
Peter Kriens
> On 12 Jul 2018, at 13:38, David Leangen via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
>
> As always, thank you VERY much to all of you for your great suggestions. I
> will look into this from tomorrow. I didn’t know the concept of “bouncing”.
> That is interesting. Now that I am aware, I will give more thought to it.
>
> One thing I have seen stated before on this list is that OSGi is indeed
> complex, but it is not accidental complexity. It is simply making complexity
> explicit, and providing the tools to work with complexity. I completely agree
> with this statement.
>
> I am still learning all the time, and am always amazed that there is still so
> much deeper to go. Thanks for helping me along this journey.
>
>
> Cheers,
> =David
>
>
>
>> On Jul 12, 2018, at 17:42, Fauth Dirk (AA-AS/EIS2-EU) via osgi-dev
>> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
>>
>> If it is a bouncing problem, than you could also try to configure the
>> behavior using the property
>>
>> ds.delayed.keepInstances=true
>>
>> From the Apache Felix documentation:
>>
>> Whether or not to keep instances of delayed components once they are not
>> referred to any more. The Declarative Services specifications suggests that
>> instances of delayed components are disposed off if there is not used any
>> longer. Setting this flag causes the components to not be disposed off and
>> thus prevent them from being constantly recreated if often used. Examples of
>> such components may be EventHandler services. The default is to dispose off
>> unused components. See FELIX-3039
>> <https://issues.apache.org/jira/browse/FELIX-3039> for details.
>>
>> http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html
>>
>> <http://felix.apache.org/documentation/subprojects/apache-felix-service-component-runtime.html>
>>
>> Equinox DS had this set by default, while the default in Felix SCR is false.
>> With the usage of Felix SCR in Eclipse we needed to explicitly set this
>> parameter to true so the previous behavior persists.
>>
>> Mit freundlichen Grüßen / Best regards
>>
>> Dirk Fauth
>>
>> Automotive Service Solutions, ESI application (AA-AS/EIS2-EU)
>> Robert Bosch GmbH | Postfach 11 29 | 73201 Plochingen | GERMANY |
>> www.bosch.com <http://www.bosch.com/>
>> Tel. +49 7153 666-1155 | dirk.fa...@de.bosch.com
>> <mailto:dirk.fa...@de.bosch.com>
>>
>> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
>> Aufsichtsratsvorsitzender: Franz Fehrenbach; Geschäftsführung: Dr. Volkmar
>> Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Rolf Bulander, Dr.
>> Stefan Hartung, Dr. Markus Heyn,
>> Dr. Dirk Hoheisel, Christoph Kübel, Uwe Raschke, Peter Tyroller
>>
>>
>> Von: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org>
>> [mailto:osgi-dev-boun...@mail.osgi.org
>> <mailto:osgi-dev-boun...@mail.osgi.org>] Im Auftrag von Tim Ward via osgi-dev
>> Gesendet: Donnerstag, 12. Juli 2018 10:22
>> An: Peter Kriens <peter.kri...@aqute.biz <mailto:peter.kri...@aqute.biz>>;
>> OSGi Developer Mail List <osgi-dev@mail.osgi.org
>> <mailto:osgi-dev@mail.osgi.org>>
>> Betreff: Re: [osgi-dev] Double config
>>
>> Hi David,
>>
>>
>> This is a gift! :-) It means your code is not handling the dynamics
>> correctly and now you know it!
>>
>> I’m not sure that there’s quite enough evidence to come to this conclusion.
>> It could simply be that everything is working fine with a static policy, and
>> working the way that DS is supposed to. In general a DS component being
>> bounced like this is nothing to worry about, it’s just a change rippling
>> through the system, and it’s typically resolved in very short order. If you
>> do want to reason about why, however, then there are several places to look.
>>
>> For some reason, the Component gets activated, deactivated, then activated
>> again, which is not desirable.
>> ...
>> 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.
>>
>> From the rest of your email it is clear that the configured component
>> provides a service. This will make it lazy by default. You have also stated
>> that you’re using has a required configuration policy. Therefore it will
>> only be activated when:
>>
>> There is a configuration present
>> All of the mandatory services are satisfied
>> Someone is actually using the service
>>
>> The component will then be deactivated when any of these things are
>> no-longer true, and so this means that your component may be being bounced
>> for several reasons, only one of which is to do with configuration.
>>
>> While it seems unlikely to me, you seem to be fairly convinced that the
>> configuration is at fault so lets start there.
>>
>> Does the generated XML file in your bundle actually say that the
>> configuration is required. This is the configuration used by DS (not the
>> annotations) at runtime. It’s unlikely that this has gone wrong, but it’s an
>> easy check
>> Do you have more than one way of putting configuration into the runtime? If
>> you are also using File Install, or some other configuration management
>> agent, then it’s entirely possible that you’re seeing a configuration update
>> occurring.
>> Do you have multiple configuration bundles which both contain a
>> configuration for this component? The configurator will process these one at
>> a time, and it will result in configuration bouncing
>> Is it possible that something is forcing a re-resolve of your configuration
>> bundle or the configurator? This could easily trigger the configurations to
>> be reprocessed.
>>
>> Now in my view the most likely reason for this behaviour is that the
>> configured component isnot being bounced due to a configuration change. The
>> most likely suspect is that the component is simply not being used at that
>> time, and so it is being disposed (DS lazy behaviour). This could easily
>> happen if one of the dependent services that you mention starts using your
>> component, and then is bounced (by a configuration update or whatever) which
>> causes your component to be released. If nobody else is using your component
>> at the time then it will be deactivated and released. The easiest way to
>> verify this is to make your component immediate. This will remove the
>> laziness, and you will get a good idea as to whether the bounce is caused by
>> things that you depend on, or by things that depend on you. If making your
>> component immediate removes the “problem” then it proves that this isn’t a
>> problem at all (and you can then remove the immediate behaviour again).
>>
>> If making your component immediate doesn’t stop the bouncing then the third
>> set of things to check is the list of services that your component depends
>> on. Is it possible that one of them is being bounced due to a configuration
>> update, or perhaps one of their service dependencies being
>> unregistered/re-registered? As I mentioned before, bouncing of DS components
>> is simply the way that updates propagate through the system when services
>> use a static policy. It isn’t inherently a bad thing, but if you want to
>> avoid it you have to be dynamic all the way down the dependency graph.
>> Usually this is a lot more effort than it’s worth!
>>
>> I hope this helps,
>>
>> Tim
>>
>>
>>
>> On 12 Jul 2018, at 08:39, Peter Kriens via osgi-dev <osgi-dev@mail.osgi.org
>> <mailto:osgi-dev@mail.osgi.org>> wrote:
>>
>> 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
>> <mailto: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 <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
