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" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*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" <[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
