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:he...@ungoverned.org] Sent: Thursday, June 03, 2010 12:00 PM To: users@felix.apache.org 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:he...@ungoverned.org] > Sent: Thursday, June 03, 2010 5:50 AM > To: users@felix.apache.org > 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: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
