Alex,
From the line numbers in the stacktrace reported by you, I see you are
using gf 3.1.2. You must have looked at gf 3.1.2 source then. There used
to be an issue in 3.1.x branch, but it has been fixed in trunk. In
trunk, we now do the following:
if (bundleProvisioner.isSystemBundleUpdationRequired()) {
logger.logp(Level.INFO, "OSGiFrameworkLauncher",
"launchOSGiFrameWork", "Updating system bundle");
framework.update();
framework.waitForStop(0);
framework.init();
*
bundleProvisioner.setBundleContext(framework.getBundleContext());*
}
We do this specifically to avoid the IllegalStateException.
Thanks,
Sahoo
On Friday 28 September 2012 08:02 PM, alex Woo wrote:
> I saw the source code both GF and Felix, found that the reason my be
> this:
>
> When new/updated/removed bundles during subsequent
> restart, BundleProvisioner#refresh() was called,
>
> and will eventually call Felix#update() which will stop and restart
> the framework on a separated thread,
>
> after Felix#stop() was called, the BundleContext come to invalidate.
>
> so, BundleProvisioner#startBundles() Failure..
>
>
> thanks
>
> Alex
>
> 2012/9/28 Sahoo <sanjeeb.sahoo_at_oracle.com
> <mailto:sanjeeb.sahoo_at_oracle.com>>
>
> [ the original submitter was missing - adding him]
>
> On Friday 28 September 2012 06:44 PM, Sahoo wrote:
>> On Friday 28 September 2012 06:40 PM, JJ Snyder wrote:
>>> Let's try this one more time...
>>> Whenever I modify anything in modules I always wipe clean the
>>> osgi-cache directory. Stop GF, go to
>>> /glassfish3/glassfish/domains/domain1/osgi-cache and remove all
>>> files and dirctories, then restart GF.
>>>
>>> JJ
>> This is actually *not* required. I rarely clean the cache. GF
>> provisioner is coded such that it takes care of
>> new/updated/removed bundles during subsequent restart. I need
>> more info from user to see what's happening. It could be a bug.
>>
>> Thanks,
>> Sahoo
>
>