pnoltes opened a new pull request, #476:
URL: https://github.com/apache/celix/pull/476

   This PR refactors the bundle cache handling so that bundles zips are not 
extracted if there is already a cache dir for that bundle.
   
   This PR does not implement or replace the ideas mentioned in #441, but 
instead is just a step to make extracted bundle cache dirs reusable. 
   
   The bundle archive, bundle cache and celix launcher functionality is tested 
with additional gtest code. 
   
   For the bundle update functionality, no additional test are added and IMO 
this functionality is still "work in progress" / "use at own risk". 
   Mainly because IMO we need to test bundle update with really different 
bundle libs (including new and removed symbols) to ensure that a dlopen/dlsym 
on the same path, but different libs really works as expected. I considered 
this out of scope for this PR.
   
   This PR also introduces:
    - Split bundle cache in a resource cache and storage cache and introduces a 
celix_bundle_getDataFile next to celix_bundle_getEntry, specifically to access 
files from the bundle storage instead of the bundle resource cache. This is 
more conform the OSGi spec, see 
https://docs.osgi.org/specification/osgi.core/8.0.0./framework.api.html#org.osgi.framework.Bundle
 getEntry and getDataFile.
    - Remove usage of -Og, because -Og actual does not really work when 
debugging (optimized out results). 
    - Introduce some additional utils functions for string to long,bool,etc 
conversion, file touch and get last modified from file functions.
    - Move (but do not change) the lib loading functionality from bundle 
archive to (bundle) module.
    - Refactor some cpputest utils test to gtest.
    - Small refactoring in start, stop and update shell command.
    - Refactor http_admin to use the storage cache instead of resource cache 
for the html files handling.
    - Add support for `--create-bundle-cache` option in the celix launcher to 
create a bundle cache and exit (i.e. prepare a application to startup more 
quickly).
   
   This PR has become large than I expected and also took more time than I 
expected. I think this is mainly, because I had some trouble understanding the 
bundle archive, revision mechanism and added quite some refactoring to (IMO) 
make this a bit cleaner. I would have preferred some more refactoring, but that 
breaks the current public api. 
   
   
   


-- 
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