It would also be beneficial to know if it's possible to avoid caching feature files.
It's quite common for someone to change the configuration section of a feature file in the deploy directory and restart only to have their changes ignored because the feature file has been cached. Having a startup flag that says "don't cache features" that the bundle deployer would honor would be most helpful. -c On Wed, Jul 7, 2010 at 6:12 PM, Matt Tennant <[email protected]> wrote: > I was wrong about what org.osgi.framework.storage.clean=onFirstInit was > doing. It turns out that it is deleting the entire bundle cache directory > and starting from scratch. I thought it was simply removing unused files > and directories, which is less useful to me. I guess I was doing some > wishful thinking. > > So I guess I should ask a new question. Is there support for what I > thought that option was doing? Basically, I want the caches for bundles > that are still in use to survive, but anything else, especially caches for > uninstalled bundles, to get removed. > > Some background: I cannot just nuke the bundle cache directory because > some bundles have been previously installed from remote URLs, and I cannot > repeat that operation every time the framework starts up. Bundles > previously installed this way must be preserved. Also, a few times we > have seen bundle cache directories get extremely bloated with caches for > bundles that are no longer installed. On an embedded device this is > catastrophic. Perhaps PackageAdmin.refreshPackages will solve this > problem, but it's hard to test for sure because the problem has not been > easily repeated. I have a workaround the looks for these directories > manually, but the workaround is very Felix-specific and I try to avoid > that sort of thing. > > Thanks for any help, > Matt > > -----Original Message----- > From: Matt Tennant [mailto:[email protected]] > Sent: Wednesday, July 07, 2010 2:02 PM > To: [email protected] > Subject: RE: bundle cache version directories > > Hi all, > > I have a follow up question from this thread I started some time ago. > Since then, I have been trying out the following property and value: > org.osgi.framework.storage.clean=onFirstInit > > Which appears to work well, and removes extraneous directories and files > from my bundle cache directory shortly after startup. Note that it > doesn't matter whether these directories and files were originally created > by Felix. If they are in the bundle cache directory, they are removed. > > I also tried calling refreshPackages(null) on the PackageAdmin service > object at runtime. When I do this, the message "FrameworkEvent PACKAGES > REFRESHED" is logged. It may be doing something, but the behavior is not > the same as with the org.osgi.framework.storage.clean property. > Extraneous directories and files are not removed. > > I was expecting the behavior to be the same between the two approaches. > Can somebody please explain the distinction? Is there runtime access to > the behavior that org.osgi.framework.storage.clean exhibits? > > In case there is some confusion, I am not worrying about precisely the > same problem as in the original thread, but instead solving a problem > where occasionally old bundle caches are present for bundles that are no > longer in use. > > Thank you, > Matt > > -----Original Message----- > From: Richard S. Hall [mailto:[email protected]] > Sent: Thursday, June 03, 2010 12:00 PM > To: [email protected] > Subject: Re: bundle cache version directories > > On 6/3/10 14:01, Matt Tennant wrote: > > That was a useful read, thank you. It leaves me with just one question: > > what triggers a framework refresh? (other than a startup/shutdown) > > > > Explicitly calling PackageAdmin.refreshPackages(), which is done by > getting the PackageAdmin service or the Felix shell provides a "refresh" > command. > > -> richard > > > From this point onward I will make a note of whether I ever see > multiple > > version directories at a point in time when I should not. > > > > Thanks! > > Matt > > > > -----Original Message----- > > From: Richard S. Hall [mailto:[email protected]] > > Sent: Thursday, June 03, 2010 5:50 AM > > To: [email protected] > > Subject: Re: bundle cache version directories > > > > On 6/2/10 19:20, Matt Tennant wrote: > > > >> Hi all, > >> > >> > >> > >> I have a question about the "versionX.X" directories inside the Felix > >> bundle cache. I am using Felix 2.0.0, and I often see something like > >> > > the > > > >> following in my bundle cache directory: > >> > >> > >> > >> > >> > >>> ls -l > >>> > >>> > >> bundle0 > >> > >> bundle1 > >> > >> ... > >> > >> > >> > >> > >> > >>> cd bundle0 > >>> > >>> > >> > >> > >>> ls -l > >>> > >>> > >> version0.1 > >> > >> version0.0 > >> > >> bundle.location > >> > >> bundle.startlevel > >> > >> bundle.lastmodified > >> > >> bundle.id > >> > >> bundle.state > >> > >> > >> > >> > >> > >>> ls -l version0.0 > >>> > >>> > >> bundle.jar > >> > >> > >> > >>> ls -l version0.1 > >>> > >>> > >> bundle.jar > >> > >> > >> > >> What I mean to be pointing out here are the two "bundle.jar" files in > >> > > two > > > >> different "versionX.X" directories in the cache area for one bundle. > >> > > What > > > >> is the reason that I might get more than one of these? How can I avoid > >> that? I have limited space on the device our product runs on, and even > >> the size of these jar files can make a difference. > >> > >> > >> > >> Note that I am using the autodeploy feature with actions > >> "install,start,update". Sometimes the original bundle jars in the > >> autodeploy directory change from one run to the next. > >> > >> > > You might want to read: > > > > > http://felix.apache.org/site/apache-felix-framework-bundle-cache.html > > > > Typically, what you are seeing is the result of doing updates. However, > > typically the extra JAR files should be deleted after a refresh. > > > > Starting with "install,start,update" causes the update, but generally > > i'd assume you'd autorefresh during startup so you wouldn't see > > additional JAR files. Perhaps you could verify that refreshing is > > deleting the JAR files. If so, you could verify that they are > > automatically getting deleted on startup. > > > > By and large, after your framework starts I'd expect there to be no > > additional JAR files and after it stops I'd expect there to be no > > additional JAR files too. At run time, it just depends on whether you've > > updated and not refreshed yet. > > > > -> richard > > > > > >> > >> Thanks, > >> > >> Matt > >> > >> > >> > >> > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
