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
