felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Egloff <andi.egl...@forgerock.com>
Subject Re: Auto installed bundle fragment inconsistently RESOLVED or INSTALLED on startup
Date Wed, 19 Oct 2011 21:44:23 GMT
Thanks Richard, so far I have not noticed anything useful. I'll see what I
can extract.

On Wed, Oct 19, 2011 at 11:41 AM, Richard S. Hall <heavy@ungoverned.org>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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message