Re: [mitk-users] Migration to MicroService based IO

[Ingmar Wegner]

Hi Sascha,

I have covered everything in [1] and [2].

I set up my module to contain usFunctionGenerateModuleInit call as mentioned in [1] and configured cmake to place the dlls inside a subfolder /mesh/debug underneath the bin folder.

I have double checked that everything defined in cmake also has an impact so in my modules visual studio subproject there is a preprocessor definition US_MODULE_NAME=mesh and the us_init.cpp file gets generated and added to the solution.

 

But the load mechanism doesn't search for the directory.

I would desperately need a description of how the US_MODULE_NAMEs or so get into the list of loaded directories.

Sorry for being so pushy... and hope to also help others when merging to MicroServices.

Ingmar

 

 

Gesendet: Mittwoch, 18. Februar 2015 um 14:36 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>
Cc: mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: Aw: Re: [mitk-users] Migration to MicroService based IO

Hi,

quick answer:

Please read [1] for the module name stuff.

The auto-load directory settings (search paths and module directory) is explained in [2].

I might be able to look into it in more detail later.

Best,
Sascha

[1] http://docs.mitk.org/2014.10/MicroServices_TheModuleContext.html

[2] http://docs.mitk.org/2014.10/MicroServices_AutoLoading.html

On 02/18/2015 02:29 PM, Ingmar Wegner wrote:

Hi Sascha,

once more thank you for your patience.

I invested some time in getting the other io modules to also be loaded from their /<modulename>/<build_type> directory and didn't get it to work. I started with a new target directory to prevent the build system to load variables that might have been definded during my tests.

 

Turned out, that my current approach was noch working. The MicroService auto load section doesn't scan for my "mesh" dir any longer.

So I asume, that something got set up while I was trying to get it working. As I also tested with cmake calls I compared the working target dir with the new one.

But the problem is that the working one contains as well definitions from an older mitk version, (2014.10.0) where the new directory structure was not in place.

 

I searched for a list that contains all auto load modules and found the modulesConf.cmake files, that are no longer in the new structure, right?

I also tried to debug up where the module strings (info) comes from but got lost in the US_GLOBAL_STATIC_WITH_ARGS method in usStaticInit_p.h. That sounds like a possible source though.

 

I asume, that if I would use the CreateModule macro everything would work.

 

As we are using our own cmake structure could you possibly explain how the module name gets into the list of scaned directories?

 

Best Regards,

Ingmar

 

Gesendet: Mittwoch, 18. Februar 2015 um 09:21 Uhr
Von: "Ingmar Wegner" <iweg...@gmx.de>
An: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
Cc: mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: [mitk-users] Migration to MicroService based IO

Hi Sascha,

thank's alot for the advice.

I got it to work for the one module. Below is a log of my setup.

 

In CMakeLists.txt of my module I am calling

...

set(module_name ${PROJECT_NAME})
set(US_MODULE_INIT_TEMPLATE ${MITK_SOURCE_DIR}/Modules/CppMicroServices/CMake/usModuleInit.cpp)
# a us_init.cpp file will be generated and has to be added to sources
list (APPEND _SRC_FILES "${CMAKE_CURRENT_BINARY_DIR}/us_init.cpp")
usFunctionGenerateModuleInit(_SRC_FILES)

add_library(

...(continued in my original/first post of this thread)

 

When I additionally call US_INITIALIZE_MODULE in the  module activator below US_EXPORT_MODULE_ACTIVATOR(MY_NAMESPACE::MeshActivator) then the compiler argues: "mesh_activator.obj : error LNK2005: _us_import_module_initializer_mesh already defined in us_init.obj"

A us_init.cpp is generated in my target/my_module directory, so that works.

 

Debugging MITKWorkbench I can see that initializing CppMicroServices the app looks for

"Z:\build\MITK-build\bin\Debug\CppMicroServices" (which doesn't exist) then for "Z:\build\MITK-build\bin\CppMicroServices\Debug" (which doesn't exist either).

Then after no service was found it continues with "MITKCore", calls MitkCoreActivator::Load(...) and then checks for ""Z:\build\MITK-build\bin\Debug\MitkCore" where it doesn't find a directory and continues with "Z:\build\MITK-build\bin\MitkCore\Debug" where it finally finds the directory. By the way, same is done with search string "MitkMapperExt" and a lot of other module names but all without success (path invalid).

So I debugged my application and placed the mesh.dll in

...target_win64-vc12\_runtime\MitkCore\Debug and then the module was auto-loaded.

Afterwards AutoLoadModulesFromPath(...) looks for "mesh" so I can also place it into ..target_win64-vc12\_runtime\mesh\Debug and it will work.

Continuing, it also tries to find all mitk auto load modules in by apps target directory. Is this worth optimizing towards only checking the ones that we know they are in the target folder?

 

Thanks for your great work; we all appreciate the work you all do on MITK a lot.

Ingmar

 

Gesendet: Dienstag, 17. Februar 2015 um 21:49 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>
Cc: mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: Aw: Re: Re: Re: Re: [mitk-users] Migration to MicroService based IO

Hi,

does your executable contain "module initialization code" as mentioned?

Did you try the "MitkCore" sub-directory?

In your MITK (not superbuild) CMake cache, you can set the US_ENABLE_DEBUG_OUTPUT variable to ON (needs to be manually added in the CMake GUI or on the command line). After recompiling MITK, this will give you debug messages including auto-load stuff.

The relevant code is here:

https://github.com/MITK/MITK/blob/master/Modules/CppMicroServices/core/src/util/usUtils.cpp#L109

Thanks,

Sascha

On 02/17/2015 09:34 PM, Ingmar Wegner wrote:

Hi Sascha,

I tried the following situation, but nothing worked out.

 

The application is in:

target_win64-vc12\_runtime\debug\my_application.exe

I tried

target_win64-vc12\_runtime\debug\main\my_module.dll

target_win64-vc12\_runtime\debug\main\debug\my_module.dll

target_win64-vc12\_runtime\main\my_module.dll

target_win64-vc12\_runtime\main\debug\my_module.dll

target_win64-vc12\main\my_module.dll

target_win64-vc12\main\debug\my_module.dll

 

Could you possibly point out where the auto-load plugin code is situated? Then I can debug it more closely.

 

Besides, did anyone also experience the warning messages in the console?

It states 2x4 times at the end of startup:

void __cdecl QWindow::setTransientParent(class QWindow *) QWidgetWindow(0x61f7fc0, name = "QWidgetClassWindow") must be a top level window.

 

This is surely QT5 related.

 

Have an nice evening,

Ingmar

 

Gesendet: Dienstag, 17. Februar 2015 um 15:49 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>
Cc: mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: Aw: Re: Re: Re: [mitk-users] Migration to MicroService based IO

Hi,

as explained below, the auto-load module must be placed in a subdirectory name "main" or "MitkCore" which is located at the same level as your application's executable (not in the same directory as your executable).

Best,
Sascha

On 02/17/2015 02:47 PM, Ingmar Wegner wrote:

Hi Sascha,

then the library is not loaded and the Load() method of my module activator is never called.

 

The module lib is located in the same directory as my application and my plugins. We don't consider having a dedicated plugins folder for now.

 

Best,

Ingmar

 

 

Gesendet: Dienstag, 17. Februar 2015 um 14:22 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>
Cc: mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: Aw: Re: Re: [mitk-users] Migration to MicroService based IO

Hi Ingmar,

On 02/17/2015 12:09 PM, Ingmar Wegner wrote:

HI Sascha,

with your hint I was able to register the io service.

Still have to set the io lib as pre-load library parameter though.

What happens if you don't? For auto-load modules, this is redundant (if the auto-loading works).

Best,
Sascha
 

But I will continue my work on this once I have everything compiling and running.

As I recently updated my fork to the mitk master I now have problems with the new directory structure.

I will write a seperate mail on this.

So thank you for your help,

;) Ingmar

 

 

Gesendet: Freitag, 13. Februar 2015 um 16:07 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>, mitk-users <mitk-users@lists.sourceforge.net>
Betreff: Re: Aw: Re: [mitk-users] Migration to MicroService based IO

Hi,

we essentially have the same set-up with our internal code base.

Please read [1] for information about auto-load paths. The activator of the MitkCore module adds the path containing the running executable to the list of auto-load paths, so putting your module's shared library into <your-exec-path>/main (if your executable contains CppMicroService initialization code) or <your-exec-path>/MitkCore should work out of the box.

Best,
Sascha

[1] http://docs.mitk.org/2014.10/MicroServices_AutoLoading.html

On 02/13/2015 03:51 PM, Ingmar Wegner wrote:

Hi Sascha,

in general I build up linker dependencies to the modules in my plugins. And before I had an awkward dependency from the app plugin to the modules that provide IO functionalites. In my WorkbenchWindowAdvisor I was registering the ObjectFactory of each module, so to say.

This time, with the micro service, I hoped to have a loose way of loading the services during startup and have them automatically registered to the MITK IO service in case they are there.

As I have an external project that links aginst MITK the solution with copying the shared lib into MITK-build is not possible. How does it work in the installed case by the way?

Is it possible to add a directory that has to be parsed for auto-loading? 

Thanks for the quick response,

Ingmar

 

 

Gesendet: Freitag, 13. Februar 2015 um 15:14 Uhr
Von: "Sascha Zelzer" <s.zel...@dkfz-heidelberg.de>
An: "Ingmar Wegner" <iweg...@gmx.de>, "Mitk Users" <mitk-users@lists.sourceforge.net>
Betreff: Re: [mitk-users] Migration to MicroService based IO

Hi Ingmar,

how is your module supposed to be loaded? By a linker dependency or as a "auto-load" module? In the latter case you need to make sure that the shared library is created in the proper sub-directory (e.g. MITK-build/(bin|lib)/MitkCore)

Best,
Sascha

On 02/12/2015 11:03 AM, Ingmar Wegner wrote:

Hi all,

I am merging our readers and writers to the new micro service based apporach but am probably missing something.

I basically stuck to Stefan K. approach for migrating the simulation module (Bug 18640). 

Before I was registering the ObjectFactory in my WorkbenchWindowAdvisor but now the autoload feature of my written micro service is supposed to do that.

 

Setup:

MSVC 2013 X64 QT 5.4 (!)

MITK checkout from 30 Jan 2015 but might stick close to the trunk until the next release once I have it working.

 

The easiest example of mine is my own vrml reader and writer.

 

So for now I implemented an activator and one vrml_io class that contains Read() and Write().

The Activator::Load() method though is never called!

(Object factory and serializer are neglected as long as the module doesn't load.)

 

I am calling

US_EXPORT_MODULE_ACTIVATOR(MyActivator);

in the body of my activator.

 

I have to mention that I am manually setting properties in my cmakelists.txt file as I am not using the macros provided by mitk.

 

see following section:

 

#start CMakeLists.txt

# Registering as mitk module with MicroService functionality

#   set template file

project(mesh)

... # ...including file.cmake
set(module_name ${PROJECT_NAME})
set(US_MODULE_INIT_TEMPLATE ${MITK_SOURCE_DIR}/Core/CppMicroServices/CMake/usModuleInit.cpp)

... # ...calling add_library(...)
#Define US_MODULE_NAME needed for MITK MicroService
set_property(TARGET ${PROJECT_NAME} APPEND PROPERTY COMPILE_DEFINITIONS US_MODULE_NAME=${module_name}) # otherwise it complains about a not set module name
set_property(TARGET ${PROJECT_NAME} PROPERTY US_MODULE_NAME ${module_name})

#end CMakeLists.txt

 

I tried to debug the other working loading modules but didn't find a difference why my one shouldn't start.

Do I have to untangle some cmake magic done in the MITK_CREATE_MODULE macro?

Which example is best for such a job?

The one in modules/core is written to also contain VTK and ITK IO and doesn't seem to me as a good example for an external project.

 

Best Regards,

Ingmar

 

P.S. Can't wait for the users meeting in April!

 

 

 

------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk_______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users