dev@glassfish.java.net

Re: Error when dynamically change 'Full profile' to 'Web profile '

From: alex Woo <alex.yueye_at_gmail.com>
Date: Sat, 29 Sep 2012 16:00:11 +0800

Sahoo,

I ported this change to my workspace, it can work well now.


Thanks,
Alex

2012/9/29 Sahoo <sanjeeb.sahoo_at_oracle.com>

> **
> I actually discovered the same by easily reproducing the issue and just
> checked in a fix. See
> http://java.net/jira/browse/GLASSFISH-19116
> for details. You are spot on with your analysis as well. You may like to
> port this change to your workspace and let me know what you see.
>
> Thanks,
> Sahoo
>
> On Saturday 29 September 2012 01:00 PM, alex Woo wrote:
>
> Sahoo,
>
> Thanks for your explanation.
>
> > I see webservices-extra-jdk-packages.jar, which is a framework
> extension bundle. So, surely we should be entering the
> > second if block as well.
>
> please note that, the value of 'systemBundleUpdationRequired' is just
> updated in BundleProvisioner#update(...) but not in
> BundleProvisioner#uninstall(...).
>
> this maybe the reason.
>
> Thanks
>
> Alex
>
>
>
> 2012/9/29 Sahoo <sanjeeb.sahoo_at_oracle.com>
>
>> Alex,
>>
>> As you must have figured out, if any bundle in modules/ is changes,
>> hasAnythingChanged() returns true. But, not all kind of change requires a
>> framework update. Only when framework extension bundles are involved, we
>> need to update the framework and that's why we call
>> bundleProvisioner.setBundleContext() in the second if block only. If
>> framework is not updated, its bundle context remains valid, so there is no
>> need to call bundleProvisioner.setBundleContext() in first if block.
>>
>> Looking at the list of bundles getting uninstalled as sent by you in your
>> first email, I see webservices-extra-jdk-packages.jar, which is a framework
>> extension bundle. So, surely we should be entering the second if block as
>> well. Let me see if I can reproduce the issue locally.
>>
>> Thanks,
>> Sahoo
>>
>>
>> On Saturday 29 September 2012 09:19 AM, alex Woo wrote:
>>
>> Sahoo,
>>
>> Thanks for you reply. Yes I am using GF 3.1.2.2. I merged the code from
>> trunk and build, but same error still occured.
>>
>> I debuged and found that it didn't enter the if block [if
>> (bundleProvisioner.isSystemBundleUpdationRequired()) ], but entered into
>> [ if (bundleProvisioner.hasAnyThingChanged())] .
>>
>> if (*bundleProvisioner.hasAnyThingChanged()*) {
>> bundleProvisioner.refresh();
>> deleteHK2Cache(); // clean hk2 cache so that updated
>> bundle details will go in there.
>> // Save the bundle ids for use during restart.
>> storeBundleIds(bundleIds.toArray(new
>> Long[bundleIds.size()]));
>> }
>> if (*bundleProvisioner.isSystemBundleUpdationRequired()*) {
>> logger.logp(Level.INFO, "OSGiFrameworkLauncher",
>> "launchOSGiFrameWork", "Updating system bundle");
>> framework.update();
>> framework.waitForStop(0);
>> framework.init();
>>
>> bundleProvisioner.setBundleContext(framework.getBundleContext());
>> }
>>
>> Adding
>> [... bundleProvisioner.setBundleContext(framework.getBundleContext());] in
>> the second if block really fix this issue?
>> After bundleProvisioner#refresh() was called, is there no need to do
>> something to ensure the refresh() really compele?
>>
>> Thanks
>>
>> Alex
>>
>>
>> 2012/9/29 Sahoo <sanjeeb.sahoo_at_oracle.com>
>>
>>> 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>
>>>
>>>> [ 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>