With regard to "testing bouncing", there are two sides to this question: the component being bounced, and the other components that may be exposed to it bouncing.
The component itself should never actually know that it is being, or has been, bounced. SCR always creates a new instance for each activation, so unless you are storing state in static fields (hopefully you don't need me to tell you that would be a bad idea!) your component only needs to deal with a straightforward start/stop lifecycle. For example when it starts, it may as well be the only time it has ever started. If you have specified optional configuration or any optional service references then you need to deal with the possibility that config/services may be null, and you should write unit tests for all combinations of config/services being unbound and unbound. Obviously you don't want too many optional references because the number of required test cases rises exponentially. The harder question is about components that deliberately expose themselves to the bouncing of other components – in other words, they have dynamic service references – and/or expose themselves to dynamic configuration changes by having a modified method. Tim talked about components that require heavyweight initialisation... to implement such a component you might write a modify method to accept dynamic config changes and then internally implement some kind of damping mechanism. This gets you into some slightly hairy multithreading code. I don't have a good answer myself yet for testing this kind of code, it seems like even the best available practices are still quite primitive and probabilistic, e.g. running the same code thousands of times and hoping to find an error. I would love to find something better. Hope this helps, Neil On Fri, Jul 13, 2018 at 8:05 PM David Leangen via osgi-dev < osgi-dev@mail.osgi.org> wrote: > > Hi Tim, > > >> What is a good way to test for robustness against this phenomenon? > > > > Again, I wish to go on record as saying that bouncing does not mean that > anything is wrong, nor is it intrinsically bad. > > Thanks. Understood. I did not mean to imply anything about “goodness” or > “badness”, but it is good to have that on record. > > So, my question was: knowing that this happens, is there a good way to > test against it? My understanding is that currently there is not. > > > Cheers, > =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
