Alternatives of Handling a Running Framework

How to handle a running framework

There is a need for manipulating configurations of not only a non-running framework but also a running framework. Other than what we propose, there are several alternatives.

Alternative 1

As same as the proposal, a bundle registers a FrameworkAdmin service for a target framework and launcher implementation where its getRunningManipulator() will return an initialized Manipulator object if the running environment is the target framework and launcher implementation.

The difference between the our proposal and the alternative 1 is, there is no service property representing whether this FrameworkAdmin object can create a Manipulator object representing a running environment, like the one keyed by FrameworkAdmin.SERVICE_PROP_KEY_RUNNING_SYSTEM_FLAG as in the proposal.

Therefore, a client bundle can get the initialized Manipulator object as follows;

String filter = null;
String clazz = FrameworkAdmin.class.getName();
ServiceReference references[] =
 context.getServiceReferences(clazz, filter);
Manipulator Manipulator = null;
For( each references[] ){
FrameworkAdmin FrameworkAdmin = (FrameworkAdmin) context.getService(references[i]);
Manipulator = FrameworkAdmin.getRunningManipulator();
	if(Manipulator!=null)
		break;
}
// Manipulator object will keep parameters set according to the running framework and launcher.

The reason why we don’t adopt alternative 1

Compared to it, our proposal has some merit and demerit.

Merit: Finding out the one that can handle the running framework and launcher is less costly. Demerit: more standardized service property name, such as FrameworkAdmin.SERVICE_PROP_KEY_RUNNING_SYSTEM_FLAG.

We adopt not alternative 1 but the proposal, because we think the merit is larger than the demerit.

Alternative 2

First, remove FrameworkAdmin#getRunningManipulator() from the API. In other words, there is no method which creates an initialized Manipulator object according to the running framework and launcher state.

In this way, by the following procedure, a client can get a Manipulator object which keeps the information about running system (framework and launcher).

 // Get values required for filtering in order to get the proper Manipulator service object that can manipulate the  running framework, <span style="color:red">somehow</span>. The information will be set as framework name/version, launcher name/version.
String filter = create filter expression using the values.
String clazz = FrameworkAdmin.class.getName();
ServiceReference references[] =
 context.getServiceReferences(clazz, filter);
FrameworkAdmin FrameworkAdmin = (FrameworkAdmin) context.getService(references[0]);
Manipulator Manipulator = FrameworkAdmin.getManipulator(); <-- not initialized.
Get Location information such as framework configuration location, framework persistent data location, and framework launcher location , <span style="color:red">somehow</span>.
Set those locations’ information to the Manipulator object.
Manipulator.load();
// parameters Manipulator keeps are set according to the running framework and launcher.

In other words, realizing the following goals will be required.

• allow a client to know the values required for filtering in order to get the target Manipulator service object that can manipulate the running framework in a framework and launcher implementation independent way.
• allow a client to know FwConfigLocation, FwPersistentDataLocation, and FwLauncherLocation of a running framework in a framework and launcher implementation independent way.

  FwConfigLocation

  This location contains the framework config files that used for a target framework launch.

  FwPersistentDataLocation

  This location contains the framework persistent data files that used for a target framework launch.

  FwLauncherLocation

  This location contains the framework launcher file that used for a target framework launch.

Both of them should be standardized.

The way for a client to know the framework name/version, launcher name/version values about running environment

In order to know the values about running framework, cooperation of framework and launcher implementation is required.

One of the standardized ways is as follows:

1. A framework implementation will receive values about its launcher name, version, and location of its executable launcher, somehow, if executable launcher is used. The way how to pass the values from a launcher to a framework implementation is dependent on their implementation. The typical way is via system properties keyed by the predefined name. A framework implementation itself can specify its framework implementation name and version.
2. Then, a framework implementation needs to tell these information to a client somehow. There are several ways to realize it.
   1. One of them is assigning these values into the framework properties keyed by the standardized “MAGIC’ name. Those framework properties can be retrieved by calling BundleContext#getProperty(name). Samples of their MAGIG names are "org.osgi.framework.service.Manipulator.fwname/fwversion/lanchername/launcherversion".
   2. The other is defining another service interface that is registered by a framework implementation and allows a client to get these information.

The way for a client to get the locations information used for the running environment

1. One of them is assigning these values into the framework properties keyed by the standardized “MAGIC’ name. Those framework properties can be retrieved by calling BundleContext#getProperty(name). Samples of their MAGIG names are "org.osgi.framework.service.Manipulator.fwconfiglocation/fwpersistentdatalocation/launcherlocation".
2. The other is defining another service interface that is registered by a framework implementation and allows a client to get these information. (it might be similar interface as org.eclipse.osgi.service.datalocation.Location)

The reason why we don’t adopt alternative 2

At this point, we would like to have less stuff to be standardized. The proposal can leave how to create an initialized Manipulator object according to the running system to the implementator of the target framework. Therefore, we choose the current proposal.