My next recommendation would be to bracket your activate and deactivate methods with print statements, including the toString/identity hash code of your component, so that you can see that:
a) The methods get called, b) The methods exit successfully c) Which objects the methods are called on > Something going wrong because of multiple configurations (even though I'm not > using any) seems favourite so far ... It is likely, but I would still take a look at whether your deactivate method is failing to stop the thread. If you do have service or configuration dependencies then your component may be getting bounced. This would fit with the logs that you have provided. Regards, Tim > On 23 Nov 2016, at 15:34, Tim Ward <t...@telensa.com> wrote: > > On 23/11/2016 15:18, Timothy Ward wrote: >> What you’re doing is fine, as long as the deactivate method stops the >> thread, and blocks until it has stopped. >> >> The activate method will only be called once by DS for a given component, >> two obvious things to ask: >> >> Are there any places in your code where calls are made to activate? > No. >> Are you sure that there’s only one component instance being created? > No. It's entirely consistent with what I'm seeing either that a single > component is having its @Activate called twice or that two different > components are being created. I don't really mind which is happening, I want > to stop it in either case! > > I don't know how you tell the difference from what's in the log, as there > doesn't seem to be any component unique ID included: > > 2016-11-23 15:24:09,642 | INFO | pool-61-thread-3 | P2cImpl > | 97 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231522 | > activate > 2016-11-23 15:24:09,647 | INFO | Thread-47 | P2cImpl > | 97 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231522 | > Thread started running > 2016-11-23 15:24:09,671 | INFO | pool-61-thread-3 | P2cImpl > | 97 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231522 | > activate > 2016-11-23 15:24:09,673 | INFO | Thread-48 | P2cImpl > | 97 - com.telensa.apps.planet.p2c.provider - 1.0.0.201611231522 | > Thread started running > >> >> For the second point, in addition to multiple configurations (as pointed out >> by others on this thread) there are some other reasons that you might have >> more than one component instance. You may, for example, have DS installed >> twice in your runtime. You don’t appear to be using any DS 1.3 features, so >> it’s unlikely that you have an extender requirement to help sort that >> particular problem out. Another possibility is that the component exists in >> two bundles, both of which are installed. > > I don't (knowingly) have it in two bundles. > > Something going wrong because of multiple configurations (even though I'm not > using any) seems favourite so far ... > >> I hope that these pointers help you to identify what is going wrong! >> >> Regards, >> >> Tim > > -- > Tim Ward > _______________________________________________ > 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
