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" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, mitk-users
<[email protected]>
*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" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, "Mitk Users"
<[email protected]>
*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*
<http://bugs.mitk.org/show_bug.cgi?id=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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
