Hi,
your application loads liborg_blueberry_osgi.dll twice. The first time,
the Windows library loader loads it from "bin/" due to the linker
dependency of your executable to it. This initializes the
berry::InternalPlatform singleton and a Poco::Util::Application instance
with the static variable _pInstance in the PocoFoundation.dll .
Then the plug-ins referenced in your provisioning files are installed
and started, which includes the bin/plugins/liborg_blueberry_osgi.dll
plug-in. Since it is loaded with an absolute path via LoadLibrary(...),
it is loaded a second time (you can see all loaded modules (DLLs) in
Visual Studio in the "Modules" view from the Debug menu). This creates
another berry::InternalPlatform singleton which tries to instantiate a
seconde Poco::Util::Application and fails due to the shared static
_pInstance in PocoFoundation.dll .
The reason why a MITK Installer works without batch files is a special
handling of liborg_blueberry_osgi during provisioning, if the
.provisioning file contains the @EXECUTABLE_DIR keyword (see
berryProvisioningInfo.cpp for details).
So in essence, duplicating plug-ins leads to faulty behavior. Please
note that you would only need a PATH entry to the plug-ins directory
containing liborg_blueberry_osgi.dll due to the linker dependency of
your executable. All plug-in directories are actually added to the
current process PATH environment variable during startup.
Best,
Sascha
On 10/19/2011 02:01 PM, Thomas Wolf wrote:
> Hi,
>
> we have some trouble debugging this...
>
> As far as i understand the code, InternalPlatform::GetInstance() is a
> singleton (after Meyers, static).
>
> So it shouldn't be possible that there is another InternalPlatform
> instance created for a second time. This happens for the first plugin,
> 'system.bundle'.
>
> After executing the singletons instance's getter, code:
>
> --->
> InternalPlatform* InternalPlatform::GetInstance()
> {
> Poco::Mutex::ScopedLock lock(m_Mutex);
> static InternalPlatform instance;
> return&instance;
> }
> <---
>
>
> ...the line 'static InternalPlatform instance;' executes the constructor
> of InternalPlatform again. This leads internally to execution of the
> base class constructor (Poco::Application), which calls setup(); There,
> the assertion fails, because the InternalPlatform has already been
> instantiated.
>
> This second call to the InternalPlatforms constructor chain happens in:
> --->
> void org_blueberry_osgi_Activator::start(ctkPluginContext* context)
> line 38:
> InternalPlatform::GetInstance()->GetBundle("system.bundle").Cast<SystemBundle>()
> <---
>
> The CallStack is attached. Anyone has an idea what is going wrong?
>
> Regards,
>
> Thomas
>
>
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
