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

[Ingmar Wegner]

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