Hi Sascha,
thanks very much! Wierdly, I found 2 plugin activators, presumably caused by
some renaming/merging confusion, which may have caused this. Either way, I
tidied up, and the problem went away.
All the rest makes good sense.
Thanks as always.
Matt
On 10 Apr 2016, at 12:16, Sascha Zelzer
<sascha.zel...@gmail.com<mailto:sascha.zel...@gmail.com>> wrote:
Hi Matt,
please see my comment inline below.
Cheers,
Sascha
On 04/07/2016 12:08 PM, Clarkson, Matt wrote:
Hi there,
I’ve just found a scenario where one of our Micro Services is registered twice
and I’m debugging whats going on.
On what platform? Maybe there is some strange symbol clash and the wrong
activator is called for a specific module?
However, in this documentation:
http://docs.mitk.org/nightly/MicroServices_Overview.html
http://docs.mitk.org/nightly/MicroServices_Example2.html
the us::ModuleActivator has Load/Unload methods. The Load basically calls
context->RegisterService, and the Unload method says the service is
automatically unloaded. This is what our service was modelled on.
This is all still valid and the idiomatic way how to do it.
However in this example, a ServiceTracker is used:
http://docs.mitk.org/nightly/MicroServices_Example7.html
And in this example, there is a ServiceRegistration and a ServiceTracker:
http://docs.mitk.org/nightly/MicroServices_Example6.html
The examples demonstrate how to use a service tracker to use *other* services.
It is complementary to registering your *own* service.
I also notice that in services like the PersistenceService and PythonService,
the Service and ServiceRegistration are both Unregistered/Deleted manually in
the Unload method.
So whats the correct or preferred approach? I just have a Module that should
register a MicroService when it is loaded, and unregister a MicroService when
it is unloaded.
It also seems to me that I have to manually delete things in the unload method.
Is that right? We have quite a few MicroServices, that Im now worrything that I
need to go and change.
I do not know why the mentioned modules registering the persistence and python
services do what they do. Albeit not required, manually unregistering the
service in the Unload method does not hurt though. However, when you have
multiple services registered in one module, there are cases where you might
want to unregister manually to control the order.
If you do not use some kind of smart pointer in your module to manage the
lifetime of your registered service, you will need to manually delete things to
prevent memory leaks. You can do it in the destructor of your activator. If you
do it in Unload, you will need to manually unregister the service first. There
is no advantage in deleting the service in Unload though (at least none of
which I can think of currently).
So, I do not think you need to change any thing here.
Thanks
Matt
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net<mailto:mitk-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
