MITK has been bitten by the static initialization and destruction order problem several times.
In a complex toolkit like MITK, consisting of multiple libraries and plug-ins, the management of static objects, especially their dependencies on each other during construction and destruction is unfeasible.
T4733 for example has been around for nearly a year due to this problem and some strategies have been discussed. Looking at other large (and much larger) frameworks and applications, this problem is often overcome by the use of a central registry managing the life-cycle and dependencies of objects added at runtime.
I suggest to use a service oriented approach like in CTK (based on OSGi) but without the module life-cycle layer. This would give us a very powerful and dynamic "service registry", enabling the design of SOA in MITK. Existing singletons would be converted into services and registered and library loading and unregistered at library unloading. Services will have no hard dependencies on each other but would use the registry for a dynamic look-up.
A prototype implementation looks like this:
//****** BEGIN ******
struct MyInterface
{
virtual void DoSomething() = 0;
};
MITK_DECLARE_SERVICE_INTERFACE(MyInterface, "org.mitk.MyInterface")
class MyImplementation : public itk::LightObject, public MyInterface
{
public:
void DoSomething() { ... }};
In some cpp file of the library declaring the MyImplementation class:
static MyImplementation* myImpl = 0;
MITK_MODULE_START(context)
{
myImpl = new MyImplementation(...); context->RegisterService<MyInterface>(myImpl);
}
MITK_MODULE_STOP(context)
{
// the service is unregistered automatically on library unloading // controlled deletion of the service object delete myImpl;
}
//******* END *******
Each module can register and unregister additional services arbitrarly
at runtime by doing
GetModuleContext()->RegisterSerivce(...)
For this to work I have done the following changes:
- Added a OSGi Service Layer implementation to MITK, based on the STL and ITK.
- Where should those files go? Core/Code/Controllers? They have names like mitkServiceFilter.h, mitkServiceProperties.h, mitkModuleContext.h, mitkModule.h, mitkModuleRegistry.h, etc.
- Where should the associated utility files go? For example mitkAtomicInt.h, mitkStaticInit.h, mitkLDAPExpr.h, mitkSharedData, etc.
- Modified the MITK_MACRO_CREATE_MODULE CMake macro to create a .cpp file for each module containing meta-information and a static initializer class.
- Added some utitlity macros to mitkCommon.h