Re: [osgi-dev] Antw: Re: Framework behaviour when extension bundle is updated

Wed, 20 Sep 2017 06:19:05 -0700

Hi,
 
Look for an updated spec draft soon.  The March draft did not include all the spec text updates for this new event.

Tom
 
 
 
----- Original message -----
From: <christoph.noe...@iwes.fraunhofer.de>
Sent by: osgi-dev-boun...@mail.osgi.org
To: <osgi-dev@mail.osgi.org>
Cc:
Subject: [osgi-dev] Antw: Re: Framework behaviour when extension bundle is updated
Date: Wed, Sep 20, 2017 3:31 AM
 
Dear Tom,
 
thanks for the explanation; good to hear that this will be clarified in the coming spec version.  
 
By the way, I looked at the published R7 draft from March (https://www.osgi.org/developer/specifications/drafts/), and found that the new FrameworkEvent is indeed introduced in the framework API reference (10.1.17), but not mentioned for instance in 
* 4.2.3 - Life cycle of a framework: states that a framework update operation leads to either STOPPED_UPDATE or STOPPED_BOOTCLASSPATH_MODIFIED; probably also STOPPED_SYSTEM_REFRESHED should be allowed
* 4.2.7 - Embedding a framework -> lists event types, but misses the new one
* 4.7.1 - Listeners -> lists event types, but misses the new one
* 10.1.17.16 - FrameworkEvent#getType documentation -> lists event types, but misses the new one
 
Best regards,
Christoph

>>> "Thomas Watson" <tjwat...@us.ibm.com> 15.09.17 23.03 Uhr >>>
This is an area that is being clarified in the OSGi R7 core specification.
 
From section 3.15 Extension Bundles
<spec>
The following steps describe the life cycle of an extension bundle:
1. When an extension bundle is installed it enters the INSTALLED state.
2. The extension bundle is allowed to enter the RESOLVED state at the Frameworks discretion, which can require a Framework re-launch.
3. If a RESOLVED extension bundle is refreshed then the Framework must shutdown; the host VM must terminate and framework must be re-launched.
4. When a RESOLVED extension bundle is updated or UNINSTALLED, it is not allowed to re-enter the RESOLVED state. If the extension bundle is refreshed then the Framework must shutdown; the host VM must terminate and framework must be re-launched.
</spec
 
3 and 4 indicate that the VM must be restarted.  The only event that gives this indication to the launcher is FrameworkEvent.STOPPED_BOOTCLASSPATH_MODIFIED.  That is the event Equinox uses for cases 3 and 4.  But that event description indicates that it is only fired (returned from Framework.waitForStop()) when a bootclasspath extension has been installed or updated.  So it seems that we are missing an event type for when framework extensions are refreshed.
 
Framework extensions are added to the framework itself.  Equinox and I suspect Felix support framework extensions by adding the extension content to the classpath of the class loader that loaded the framework implementation.  In the case of a refresh all that is really needed is a new class loader for the framework implementation. 
 
In OSGi R7 we are relaxing 3 and 4 to not require a VM restart in the case of a framework extension and instead we have defined a new FrameworkEvent (STOPPED_SYSTEM_REFRESHED) that indicates that the framework has been refreshed and is in need of being re-launched with a new class loader.
 
Before we lacked the event that would indicate that the launcher needs to restart the framework with a new class loader because some extension content has changed or been refreshed.  Equinox choose to use the STOPPED_BOOTCLASSPATH_MODIFIED while it appears others use the STOPPED_UPDATE.  I'm unsure on the details of how Felix or Knopflerfish deals with restarts when this event is fired in this case.  But it is unclear how they could relaunch without a new class loader and still be correct since framework extensions are required by the spec to be loaded with the same class loader which loaded the framework itself.  So there is little to be done to unload and discard the old extension classes short of throwing away the class loader used to load the framework.
 
Here is the javadoc for the new event type STOPPED_SYSTEM_REFRESHED:
 
The Framework has stopped and the framework requires a new class loader to restart.
This event is fired when the Framework has been stopped because of a stop operation on the system bundle and the framework requires a new class loader to be used to restart. For example, if a framework extension bundle has been refreshed. The source of this event is the System Bundle.

Tom
 
 
 
----- Original message -----
From: <christoph.noe...@iwes.fraunhofer.de>
Sent by: osgi-dev-boun...@mail.osgi.org
To: <osgi-dev@mail.osgi.org>
Cc:
Subject: [osgi-dev] Framework behaviour when extension bundle is updated
Date: Thu, Sep 14, 2017 7:24 PM
 
Hi everyone,
 
I have an issue with different behaviours of some open source framework bundles (Felix, Equinox, Knopflerfish) when a framework extension bundle is updated programmatically, and wonder what the correct behaviour should be. The spec seems contradictory regarding this. In a test setting I have an extension bundle in two versions 0.0.1 and 0.0.2, exporting two different packages test.pck1 and test.pck2, respectively. Updating the extension bundle from 0.0.1 to 0.0.2 and calling framework.refreshBundles(null) causes the framework to stop for all three implementations. Furthermore, it causes the blocking method framework.waitForStop(0) to return a FrameworkEvent. Then:
 
* Felix: FrameworkEvent is of type STOPPED_UPDATE and the framework immediately restarts. Afterwards it exports both test.pck1 (a bug?) and test.pck2, until restarted in a fresh VM. Then only test.pck2 is exported.
* Knopflerfish: FrameworkEvent is of type STOPPED_UPDATE and the framework immediately restarts. Afterwards it exports only test.pck2
* Equinox: FrameworkEvent is of type STOPPED_BOOTCLASSPATH_MODIFIED, the framework does not restart. After a restart in a fresh JVM it exports only test.pck2
 
I am wondering in particular about the two questions:
1) Which is the correct FrameworkEvent type to expect here? 
2) Should the framework restart, or simply shutdown? 
 
Regarding the FrameworkEvent type, the spec states (core 6.0.0, p. 105):
 
• STOPPED_UPDATE - This Framework object has been updated. The framework will begin to
restart. The framework will return to its state before it was updated, either ACTIVE or STARTING.
• STOPPED_BOOTCLASSPATH_MODIFIED - This framework object has been stopped because a
boot class path extension bundle has been installed or updated. The VM must be restarted in order
for the changed boot class path to take affect.
 
This would indicate that Felix and Knopflerfish are correct, since no boot class path extension bundle has been updated (rather a normal extension bundle).
On the other hand, the section on Extension Bundles states that (p. 85):
 
When a RESOLVED extension bundle is updated or UNINSTALLED, it is not allowed to re-enter
the RESOLVED state. If the extension bundle is refreshed then the Framework must shutdown;
the host VM must terminate and framework must be re-launched.
 
Unfortunately, it does not specify the FrameworkEvent to expect, but in any case this is consistent with the Equinox behaviour and not with Felix and Knopflerfish. It seems impossible to satisfy both requirements. 
 
Bonus question: why does the spec insist that extension bundle updates lead to a framework shutdown and not a restart, or why is it necessary to restart in a fresh VM? Apparently the Knopflerfish implementation manages to restart in the current VM with the correct package exports. Seems to be the most convenient solution.
 
Thanks in advance,
Christoph
 
 

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to