Difference between revisions of "Alternatives of Handling a Running Framework"

Revision as of 16:00, 24 January 2007

How to handle a running framework

This document is related with FrameworkHandler.

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

Alternative 1

First, leave getFwHandlerRunning() method in FwHandlerAdmin interface as an API.

1. A bundle registers a FwHandlerAdmin service for a particular fw and launcher implementation. Here, getFwHandlerRunning() of the FwHandlerAdmin object will return an initialized FwHandler object if the running environment is the target fw and launcher implementation. Otherwise, it will return null.

The difference between the our proposal and this is, there is no service property representing whether this FwHandlerAdmin object can create a FwHandler object representing running environment, like the one keyed by FwHandlerAdmin.SERVICE_PROP_KEY_RUNNING_FW_FLAG.

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

String filter = null;
String clazz = FwHandlerAdmin.class.getName();
ServiceReference references[] =
 context.getServiceReferences(clazz, filter);
FwHandler fwHandler = null;
For( each references[] ){
FwHandlerAdmin fwHandlerAdmin = (FwHandlerAdmin) context.getService(references[i]);
fwHandler = fwHandlerAdmin.getFwHandlerRunning();
	if(fwHandler!=null)
		break;
}
// parameters fwHandler keeps are set according to the running fw 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 fw and launcher is less costly. Demerit: more standardized service property name, such as FwHandlerAdmin.SERVICE_PROP_KEY_RUNNING_FW_FLAG.

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

Alternative 2

First, remove getFwHandlerRunning() method in FwHandlerAdmin interface as an API. In other words, there is no method which creates an initialized FwHandler object according to the running fw and launcher state.

In this way, by the following procedure, a client can get a FwHandler object which keeps the information about running fw.

 // Get values required for filtering in order to get the proper FwHandler service object that can manipulate the  running fw, somehow. The information will be set as fw name/version, launcher name/version.
String filter = create filter expression using the values.
String clazz = FwHandlerAdmin.class.getName();
ServiceReference references[] =
 context.getServiceReferences(clazz, filter);
FwHandlerAdmin fwHandlerAdmin = (FwHandlerAdmin) context.getService(references[0]);
FwHandler fwHandler = fwHandlerAdmin.getFwHandler(); <-- not initialized.
Get Location information such as fw configuration location, fw persistent data location, and fw launcher location , somehow.
Set those locations’ information to the fwHandler object.
fwHandler.load();
// parameters fwHandler keeps are set according to the running fw 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 FwHandler service object that can manipulate the running fw in a fw and launcher implementation independent way.
• allow a client to know FwConfigLocation, FwPersistentDataLocation, and FwLauncherLocation of a running fw in a fw and launcher implementation independent way.

  FwConfigLocation

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

  FwPersistentDataLocation

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

  FwLauncherLocation

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

Both of them should be standardized.

Instead, there is no method which creates an initialized FwHandler object according to the running fw and launcher state.

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

In order to know the values about running fw, cooperation of fw and launcher implementation is required. One of the standardized ways is as follows:

1. A fw 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 fw implementation is dependent on their implementation. The typical way is via system properties keyed by the predefined name. A fw implementation itself can specify its fw implementation name and version.
2. Then, a fw 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.fwhandler.fwname/fwversion/lanchername/launcherversion".
   2. The other is defining another service interface that is registered by a fw 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.fwhandler.fwconfiglocation/fwpersistentdatalocation/launcherlocation".
2. The other is defining another service interface that is registered by a fw 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. Therefore, we choose the current proposal.