Thanks Richard, so far I have not noticed anything useful. I'll see what I can extract. Andi
On Wed, Oct 19, 2011 at 11:41 AM, Richard S. Hall <[email protected]>wrote: > Perhaps you could set felix.log.level to 4 in conf/config.properties to see > if you get any additional information. If not, perhaps you could zip > something up and send it to me privately to see if I could recreate it? > > -> richard > > > On 10/19/11 12:26 , Andreas Egloff wrote: > >> We have one bundle fragment that does not consistently go to RESOLVED >> state >> after a re-start, but occasionally stays INSTALLED without a visible >> failure. We have not observed issues with other fragments we use. >> >> The bundle fragment is installed via config.properties, although the same >> seemingly random behavior was observed when placing the fragment alongside >> the host bundle in the auto start dir. >> felix.auto.install.1 >> >> The bundle it attaches to is a bundle in the auto start directory (start >> level 10). >> >> The fragment imports one additional package (auto started bundle with >> start >> level 1); the intent being to attach this to the host. >> >> It seems to be reproducible more so on some platforms/environments than >> others. Typically the first start is successful; with subsequent restarts >> randomly working or not. >> >> Enabling org.osgi.framework.storage.**clean=onFirstInit seems to resolve >> or >> improve the situation, but in case this is a timing/ordering issue it is >> possible that this is not fully resolving the cause. It also seems more >> reproducible on some platforms/environments than others. >> >> Would you have recommendations on obtaining further data/output as to why >> the fragment does not consistently go to RESOLVED? >> >> Thanks >> Andi >> >>
