Autoload bundles

[fmilano]

I'm looking into writing a bundle to implement autoloading for bundles (this should not require any change in the framework at all). This is the first step to migrate the CppMicroServices version of MITK to the lastest CppMicroServices.

I'm opening this issue to discuss different interface and implementation options.

@saschazelzer suggested using Apache Felix File Install as a source for the bundle design. What functionality do you think we should define first?

An important implementation decision would be selecting between std::filesystem (and moving to C++17) or using a third party library/implementing the directory monitoring by ourselves.

[jeffdiclemente]

@fmilano If MITK is currently using CppMicroServices 2.x and its auto-loading feature is sufficient for MITK, one idea could be to implement the auto-loading feature which exists in CppMicroServices 2.x as a bundle using CppMicroServices 3.x. If the auto-loading in 2.x already meets your requirements, that may be an easier path towards migrating MITK. What do you think?

As for the decision to use std::filesystem or something else, I believe in the long term std::filesystem is the way to go and boost offers a clean migration path to std::filesystem if you aren't ready to adopt C++17 yet.

[fmilano]

Hi. For watching a directory for changes (new bundles, updated bundles, deleted bundles) I would need to start a background task, probably using a thread to poll the directory. Do you foresee any issues if a shared_ptr to the BundleContext is kept in a background thread and used for installing/uninstalling the detected bundles?

[jeffdiclemente]

as long as the thread's lifetime is scoped to the lifetime of the BundleContext object used by the thread, I don't see an issue. If the BundleContext object's lifetime can't be guaranteed to outlive the thread's lifetime then a check needs to be made before using the BundleContext as it could have been invalidated through a call to BundleContext::Stop or shutting down the CppMicroServices framework on another thread.

To scope the thread's lifetime you could create a bundle and start the thread in the bundle's BundleActivator::Start method and stop and join the thread in the BundleActivator::Stop method, which would guarantee that the BundleContext is valid for the lifetime of the thread. This way you don't have to check for a valid BundleContext object in the thread.

[fmilano]

I'm thinking of filtering the monitored files by their extension, to avoid computing a checksum of files that are definitively not bundles. What do you think of such a design decision? Is there an efficient way to check if a file is an installable bundle? Or the best way is to try to install it and see if it fails or not? Best regards, Federico

…

On Mon, Aug 2, 2021, 10:22 PM Jeff DiClemente ***@***.***> wrote: as long as the thread's lifetime is scoped to the lifetime of the BundleContext object used by the thread, I don't see an issue. If the BundleContext object's lifetime can't be guaranteed to outlive the thread's lifetime then a check needs to be made before using the BundleContext as it could have been invalidated through a call to BundleContext::Stop or shutting down the CppMicroServices framework on another thread. To scope the thread's lifetime you could create a bundle and start the thread in the bundle's BundleActivator::Start method and stop and join the thread in the BundleActivator::Stop method, which would guarantee that the BundleContext is valid for the lifetime of the thread. This way you don't have to check for a valid BundleContext object in the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPDYE7GMNUQCGPSCU4VULDT235BXANCNFSM4HQFZKHQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .