Remove static globals #31
Conversation
Added disclaimer describing the purpose of this repository. Signed-off-by: The MathWorks, Inc. Roy.Lurie@mathworks.com
This includes a few other changes required to be able to remove static globals: - "Framework" and "Framework Factory" classes as a single entry point for clients to initialize CppMicroServices. - A minimal lifecycle for bundles, consisting solely of "install", "start", "stop" and "uninstall". - Bundles are installed first and then loaded into the process only on bundle activation. - Transition to declaring the bundle name in the bundle's manifest file. - Auto-loading needs to be either factored out into a service or modified to allow auto-installing of bundles. Closes #2 Signed-off-by: The MathWorks, Inc. Roy.Lurie@mathworks.com
|
I'm not sure why the AppVeyor build fails. It has consistently done so with the following output:
Is this an issue on the AppVeyor side or an issue on my end? |
| @@ -16,9 +16,7 @@ void RetrieveModuleContext() | |||
| //! [GetModuleContext] | |||
|
|
|||
| //! [InitializeModule] | |||
|
Concerning the AppVeyor issue, I am not sure what's going on. Lets ignore this for now, we can fix the build later. |
| @@ -7,15 +7,22 @@ The following properties are always set by the C++ Micro Services library and ca | |||
| the module author: | |||
|
|
|||
| * `module.id` - The unique id of the module (type `long`) | |||
| * `module.name` - The human readable name of the module (type `std::string`) | |||
There was a problem hiding this comment.
I believe I understand why you made this change. Still, I would like to see the module.name property added by the framework, such that for basic bundles no custom manifest.json file is required.
We should be able to use the US_MODULE_INITIALIZATION macro to inject a string field into the custom section we were talking about in the General Discussion document. The existing object format parsers in branch 25-module-lifecycle-enhancements can then extract that information. Because this requires some more coding, I suggest to keep your changes for the sake of merging them rather sooner than later. I will create a separate issue to investigate this after the merge.
| * | ||
| * @return A new, configured Framework instance. | ||
| */ | ||
| Framework* newFramework(std::map<std::string, std::string> configuration); |
There was a problem hiding this comment.
Camel case method naming NewFramework.
Please add an overload taking no arguments.
There was a problem hiding this comment.
We probably should use unique / shared pointer for the framework and module instances. Previously, the Module pointers lived as long as the program, but with the new life cycle they should be managed. I will create a new issue for that.
All issues in the code review should be addressed, excluding those that have circle back issues associated with them. In addition, other issues were fixed: 1. removed more unnecessary #includes. 2. fixed the usCoreExamplesDriver to work with static modules. 3. Removed references in the documentation and CMakeLists.txt files to the US_STATIC_MODULE preprocessor. Signed-off-by: The MathWorks, Inc. Roy.Lurie@mathworks.com
An incorrect build option was being used in the test. Signed-off-by: The MathWorks, Inc. Roy.Lurie@mathworks.com
|
@saschazelzer, please let me know if there is anything else which requires immediate attention before it can be merged into the development branch. Thanks. |
|
Strange, I didn't get any notification about your new changes but maybe I just missed it. I will have a final look and merge it asap. Thanks! |
|
All right, thanks a lot for this massive contribution. I will add the discussed todos as new issues. |
This addresses jeffdiclemente#2, which is concerned with removal of static globals and other related code changes.
This pull request obsoletes #28, which was primarily focused on the review of the high level design.
Important Notes: