pnoltes commented on code in PR #476:
URL: https://github.com/apache/celix/pull/476#discussion_r1153569792


##########
libs/framework/src/framework.c:
##########
@@ -1243,7 +1121,7 @@ static celix_status_t 
framework_markBundleResolved(framework_pt framework, modul
             bool isSystemBundle = false;
             bundle_isSystemBundle(bundle, &isSystemBundle);
             if (!isSystemBundle) {
-                status = CELIX_DO_IF(status, 
framework_loadBundleLibraries(framework, bundle));
+                status = CELIX_DO_IF(status, 
celix_module_loadLibraries(module));

Review Comment:
   Yeah I know.
   
   After this PR, I think a  important thing to tackle next is updating the 
module resolver. 
   Why? Because this code contains lot of comments, not explicitly tested 
functionality and clearly not thread safe or reentrant code. 
   
   Generally speaking the idea of module resolvement - if I got this correct - 
is to solve the export / import of the "packages" ("package in java, libraries 
in C) or more broader to solve the provided and required capabilities between 
bundles.
   
   For example for OSGi you can provide a capability in the MANIFEST.MF as 
follows:
   ```
   Provide-Capability: example.namespace;key1="value1";key2="value2"
   ```
   This way a bundle provide a capability in the namespace "example.namespace" 
with two property values (key1=value1 key2=value2). 
   
   
   And also require capability in the MANIFEST.MF as follows:
   ```
   Require-Capability: example.namespace;filter:="(&(key1=value1)(key2=value2))"
   ```
   
   Celix has some support for this, together with trying to the solve the 
import/export of the libraries in the following c files:
   attribute.c
   capability.c
   requirement.c
   wire.c
   resolver.c
   
   But I am not yet familiar with this code and only changes some types names. 
I do know that - for example - the resolver.c uses global variables (i.e. it is 
not reentrant). 
   
   So although I know the `framework_markResolvedModules` has quite some 
commented out code and the above mentioned files could use a good refactor, I 
prefer to this in a separate PR. 
   
   To be honest, I do not think the resolver functionality can be refactored 
without bumping Celix to 3.0.0 due to exposed API of the wire, capability, etc. 
   
   So for this PR I try not to touch anything about the resolver expect that I 
moved the loadLibraries from bundle to module. 
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to