Could you please raise a JIRA issue at https://issues.apache.org/jira/browse/KARAF ?
On Thu, Jul 8, 2010 at 00:18, Chris Blunck <[email protected]> wrote: > 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] >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
