Community
Participate
Working Groups
RFC 132 defines a new SystemBundle interface which Framework implementations must provide an implementation to. This implementation can be used to launch an OSGi Framework in a standard way. The SystemBundle extends the Bundle object and provides a configurator (boot strap code) with a specified way to control the lifecycle of the Framework through the use of the start/stop/update methods. It also provides an init method which can be used to configure an instance of the framework. Implementing this is pretty straight forward. The sticky part comes when multiple framework instances are created using the same classloader. In Equinox we have made lots of assumptions that only one instance of the framework is loaded with a given classloader. In past releases Equinox has supported multiple frameworks loaded into the same VM by created isolated classloaders for each instance of the Framework. In order to support RFC 132 and other enhancements coming in OSGi R4.2 we will need to figure out how allow for the SystemBundle implementation instances to share the same classloader. One approach is to create a child first classloader that allows for the internal guts of the framework to be loaded by a separate classloader for each instance but allow all publich APIs (org.osgi.* etc.) to be loaded by a single parent class loader.
(In reply to comment #0) > One approach is to create a child first classloader that allows for the > internal guts of the framework to be loaded by a separate classloader for each > instance but allow all publich APIs (org.osgi.* etc.) to be loaded by a single > parent class loader. > I have been working on this approach and plan to release something into M2.
Created attachment 110287 [details] initial implementation Work in progress. Implementation of SystemBundle + testcases.
Created attachment 110297 [details] Updated patch Previous patch inadvertently added API to EclipseStarter. I released this patch for M2. I expect more changes to come from RFC 132 and RFC 138. Leaving this bug open for now.
Note that I did not tag this for the I-Build tomorrow. I would like to run an N-Build test pass first.
Is there any correspondance between this and the framework admin stuff that we have worked on in Equinox? Hopefully framework admin can at least in part be implemented in terms of this.
(In reply to comment #5) > Is there any correspondance between this and the framework admin stuff that we > have worked on in Equinox? Hopefully framework admin can at least in part be > implemented in terms of this. > My high level understanding of framework admin is that it provides API that manipulates configuration data that gets used by a runtime. Conceptually it manipulates two types of data: - launcher and boot strap configurations: Things like splash screen and installation of the "configurator" bundle. - input data for the configurator bundle which describes the bundles that should be installed into the framework and the start information (start-level, persistent start etc.) The manipulators in Framework Admin do not actually manipulate the framework directly. Instead they manipulate data for which boot strap and configurator code uses to interact with the framework. In RFC 132 (public draft will be available by the end of this week) OSGi is defining a standard way for launching an instance of an empty framework. The design is very simple. Framework Implementations must provide a public class which implements the SystemBundle interface. The SystemBundle interface extends Bundle and provides an init method which takes a Properties object used to pass configuration properties to the framework (think of this as the content of the config.ini). A SystemBundle implementation then could be used by boot strap code to install the "configurator" bundle (through the use of SystemBundle.getBundleContext()). I think this is orthogonal to framework admin's main uses. It looks like framework admin does have API to launch a framework but I'm not sure that is the main focus of framework admin. Perhaps this portion of framework admin could use RFC 132 to launch an instance of a framework. My goal is to update the launcher/EclipseStarter to use a standard way to launch a framework and install boot strap bundles instead of using internal classes of Equinox to construct the framework. Also keep in mind that RFC 132 is a spring board to other, more involved, changes to the framework for specifying how to have embedded/peered/child framework instances.
PDE is interested in any universal way to launch frameworks.
thanks Tom. We should definitely make framwork admin use the new API. Does the new API talk about how to start an entire framework (e.g., Java, vm args, ...) or just how to start another framework in the currently running VM?
(In reply to comment #8) > thanks Tom. We should definitely make framwork admin use the new API. Does > the new API talk about how to start an entire framework (e.g., Java, vm args, > ...) or just how to start another framework in the currently running VM? > It only specifies how to launch a framework in a currently running VM from what I call "boot strap code". This is something like EclipseStarter. So in theory EclipseStarter could be abstracted out of the Framework and used to launch an Framework implementation that implements RFC 132.
See http://www.osgi.org/download/osgi-4.2-early-draft.pdf for early draft which includes RFC 132.
No additional work is going to be done in M2. The specification is being updated and the API will change. We will update the implementation to be in line with the new draft spec in M3.
Marking as fixed. I released the latest changes to be inline with the latest RFC. New bugs will be opened if additional changes are needed.
Where can I find equinox with the new SystemBundle? Target Milestone of this issue was 3.5 M3. I've downloaded Equinox 3.5, but there is no such class. [1] http://download.eclipse.org/equinox/drops/R-3.5-200906111540/index.php
(In reply to comment #13) > Where can I find equinox with the new SystemBundle? Target Milestone of this > issue was 3.5 M3. I've downloaded Equinox 3.5, but there is no such class. > > [1] http://download.eclipse.org/equinox/drops/R-3.5-200906111540/index.php > RFC 132 has undergone many changes leading up to the final version of the v4.2 OSGi specification. You can find the interfaces related to this RFC in the org.osgi.framework.launch package. You are looking for the org.osgi.framework.launch.Framework interface.
Thank you very much for your help! Am I right that all the org.osgi.service.command stuff was also not included into the final version of the v4.2?
(In reply to comment #15) > Thank you very much for your help! > > Am I right that all the org.osgi.service.command stuff was also not included > into the final version of the v4.2? > Correct, the command stuff did not make it into the summer release of the compendium specification (r4.2).
