Page History

...

• Downloading the Framework
• Starting the Framework
• Framework Shell
  • Installing Bundles
  • Web Proxy Issues when Installing Bundles
• Bundle Auto-Deploy
• Configuring the Framework
  • Migrating from Earlier Versions
  • System Property Substitution
• Configuring Bundles
• Feedback

...

The framework launcher starts the framework and installs a and starts all bundles contained in the bundle directory of the current directory. By default, the bundle directory contains a simple text-based shell shell-related bundles providing a textual user interface to interact with the framework. Bundles installed into the framework are copied into a bundle cache directory for subsequent executions. By default, the framework creates a cache directory, called felix-cache, in your current working directory; this behavior is configurable, see the Apache Felix Framework Bundle Cache document for more details. If you want to start the framework using a different bundle cache directory, you can do so like this:

...

The main way to interact with the framework is via its shell. Felix' shell is implemented as an OSGi service that, be default, uses a simple text-based user interface. After starting the framework, type help into the shell the supplied Apache Felix Gogo shell. After starting the framework, type help into the shell to see the list of the available commands and help <command-name> to get help for a specific command.

To install bundles, use the install command, which is described in more detail in the next sub-section. To view all currently installed bundles, use the ps command. To stop the framework type stop 0 to stop the System Bundle; any installed bundles will automatically be reloaded (and potentially restarted) the next time you launch with the associated cache.

...

To install bundles, use the felix:install command, which is described in more detail in the next sub-section. To list installed bundles, use the felix:lb command. To stop the framework type stop 0 to stop the System Bundle; any installed bundles will automatically be reloaded (and potentially restarted) the next time you launch with the associated cache.

Installing Bundles

A bundle is the OSGi term for a component for the OSGi framework. A bundle is simply a JAR file containing a manifest and some combination of Java classes, embedded JAR files, native code, and resources. A bundle may

...

Installing Bundles

A bundle is the OSGi term for a component for the OSGi framework. A bundle is simply a JAR file containing a manifest and some combination of Java classes, embedded JAR files, native code, and resources. A bundle may provide some specific functionality for the user or it may implement a service that other bundles can use; bundles can only use functionality from other bundles through shared services and packages.

The Felix framework is packaged distribution comes with three bundles, which are located in the bundle/ directory of the framework distribution installation directory. There are These bundles for the Felix shell service, a include the Gogo Runtime (core command processing functionality), Gogo Shell (text-based shell service user interface), Gogo Command (basic set of commands), and Bundle Repository (a bundle repository service). In addition to these bundles, the bundle repository services provides access to other bundles for easy installation. The bundle repository service provides a shell command, named obr, to access available bundlesset of shell commands in the obr:* scope; refer to the Apache Felix OSGi Bundle Repository for more information.

Before installing any bundles, it is important to understand how bundles are manually deployed into the framework. Bundles are deployed in two stages; first they are installed, then they are started. To install a bundle use the felix:install shell command followed by a bundle URL. For example, to install a bundle.jar bundle you type (assuming you have started Felix from its installation directory):

felix:install file:/path/to/bundle/bundle.jar

Once a bundle is installed, it can then be started by using the felix:start command and the bundle identifier of the desired bundle. The ps shell felix:lb command is used to list all installed bundles and to obtain the bundle's identifier. The following Felix shell session capture illustrates how to start the bundle.jar bundle:

->g! install [file:/path/to/bundle/simple]
-> psbundle.jar
g! lb
START LEVEL 1
   ID   |State         Level  |Level|Name
[    0] [|Active     ] [|    0] |System Bundle (23.0.0)
[    1] [|Active     ]| [   1|Apache 1]Felix ShellBundle ServiceRepository (1.46.02)
[    2] [|Active     ]| [   1|Apache 1]Felix ShellGogo TUICommand (10.46.0)
[    3] [|Active     ] [|    1] Bundle Repository|Apache Felix Gogo Runtime (10.46.0)
[    4]|Active  [Installed  ] [|    1] Bundle Example|Apache Felix Gogo Shell (10.06.0)
-> start 4
Hello from Bundle 4.
->
    5|Installed  |    1|Example Bundle (1.0.0)
g! start 5
Hello from Bundle 5.
g!

The felix:The stop command is used to stop a bundle and the felix:uninstall command is used to remove a bundle from the bundle cache. As an alternative to using the felix:install and felix:start commands explicitly, it is also possible to install and start a bundle in one step by using the felix:start command with a bundle URL.

Bundles can be updated using the felix:update command. The update command allows you to specify an URL from which to retrieve the updated bundle, but if one is not specified it will try to update the bundle from the bundle's Bundle-UpdateLocation manifest attribute, if present, or the bundle's original location URL.Important:

...

For For an introduction to writing bundles and services, refer to the Felix bundle tutorial.

...

If you use a proxy for Web access, then you may run into difficulty using the Felix Gogo shell to install bundles from a remote URLURLs. To remedy this situation, certain system properties must be set to make Felix the framework work with your proxy. These properties are:

...

Specifying an auto-deploy directory replaces the default directory, it does not augment it. The default deployment actions performed on the framework distribution is configured to install and start bundles in the auto-deploy directory are: install, update, and start. Both the location of the auto-deploy directory and the deployment actions performed can be controlled by the following configuration properties, respectively:

• felix.auto.deploy.dir - Specifies the auto-deploy directory from which bundles are automatically deploy at framework startup. The default is the bundle/ directory of the current directory.
• felix.auto.deploy.action - Specifies the auto-deploy actions to be found performed on the bundle JAR files found in the auto-deploy directory. The possible actions are install, update, start, and uninstall. If no actions are specified, then the auto-deploy directory is not processed (i.e., it is disabled). There is no default value for this property, but the default config.properties file installed with the Felix framework distribution sets the value to: install, update, and start.

The next section describes how to set and use configuration properties.

...

Both the Felix framework and the launcher use configuration properties to alter their default behavior. The framework can only be configured by passing properties into its constructor, but the launcher provides a mechanism to configure the framework via a property file. The launcher The Felix framework uses properties to configure certain aspects of its behavior. The framework launcher reads configuration properties from conf/config.properties. This file uses standard Java property file syntax.

...

It is possible to specify a different locations for these property files for the system properties file by using the felix.config.properties and felix.system.properties system properties when executing the framework. For example:

...

Configuration and system properties are accessible at run time via BundleContext.getProperty(), but configuration properties override system properties.

The following configuration properties are specifically for the launcher:

• felix.auto.deploy.dir - Specifies the auto-deploy directory from which bundles are automatically deploy at framework startup. The default is the bundle/ directory of the current directory.
• felix.auto.deploy.action - Specifies the auto-deploy actions to be found on bundle JAR files found in the auto-deploy directory. The possible actions are install, update, start, and uninstall. The default value is install, update, and start.
• felix.auto.install.<n> - Space-delimited list of bundle URLs to automatically install when Felix is started, where <n> is the start level into which the bundle will be installed (e.g., felix.auto.install.2).
• felix.auto.start.<n> - Space-delimited list of bundle URLs to automatically install and start when Felix is started, where <n> is the start level into which the bundle will be installed (e.g., felix.auto.start.2).
• felix.shutdown.hook - Specifies whether the launcher should install a shutdown hook to cleanly shutdown the framework on process exit. The default value is true.

The following configuration properties are specifically for the framework (properties starting with "felix" are specific to Felix, while those starting with "org.osgi" are standard OSGi properties):

• org.osgi.framework.storage - Sets the directory to use as the bundle cache; by default bundle cache directory is felix-cache in the current working directory. The value should be a valid directory name. The directory name can be either absolute or relative. Relative directory names are relative to the current working directory. The specified directory will be created if it does not exist.
• felix.cache.rootdir - Sets the root directory to use to calculate the bundle cache directory for relative directory names. If org.osgi.framework.storage is set to a relative name, by default it is relative to the current working directory. If this property is set, then it will be calculated as being relative to the specified root directory.
• org.osgi.framework.storage.clean - Determines whether the bundle cache is flushed. The value can either be "none" or "onFirstInit", where "none" does not flush the bundle cache and "onFirstInit" flushes the bundle cache when the framework instance is first initialized. The default value is "none".
• felix.cache.bufsize - Sets the buffer size to be used by the cache; the default value is 4096. The integer value of this string provides control over the size of the internal buffer of the disk cache for performance reasons.
• org.osgi.framework.system.packages - Specifies a comma-delimited list of packages that should be exported via the System Bundle from the parent class loader. The framework will set this to a reasonable default. If the value is specified, it replaces any default value.
• org.osgi.framework.system.packages.extra - Specifies a comma-delimited list of packages that should be exported via the System Bundle from the parent class loader in addition to the packages in org.osgi.framework.system.packages. The default value is empty. If a value is specified, it is appended to the list of default or specified packages in org.osgi.framework.system.packages.
• org.osgi.framework.bootdelegation - Specifies a comma-delimited list of packages that should be made implicitly available to all bundles from the parent class loader. It is recommended not to use this property since it breaks modularity. The default value is empty.
• felix.bootdelegation.implicit - Specifies whether the framework should try to guess when to implicitly boot delegate to ease integration with external code. The default value is true.
• felix.systembundle.activators - A List of BundleActivator instances that are started/stopped when the System Bundle is started/stopped. The specified instances will receive the System Bundle's BundleContext when invoked. (This property cannot be set in the configuration file since it requires instances; it can only be passed into Felix' constructor directly.)
• felix.log.logger - An instance of Logger that the framework uses as its default logger. (This property cannot be set in the configuration file since it requires an instance; it can only be passed into Felix' constructor directly.)
• felix.log.level - An integer value indicating the degree of logging reported by the framework; the higher the value the more logging is reported. If zero ('0') is specified, then logging is turned off completely. The log levels match those specified in the OSGi Log Service (i.e., 1 = error, 2 = warning, 3 = information, and 4 = debug). The default value is 1.
• org.osgi.framework.startlevel.beginning - The initial start level of the framework once it starts execution; the default value is 1.
• felix.startlevel.bundle - The default start level for newly installed bundles; the default value is 1.
• felix.service.urlhandlers - Flag to indicate whether to activate the URL Handlers service for the framework instance; the default value is "true". Activating the URL Handlers service will result in the URL.setURLStreamHandlerFactory() and URLConnection.setContentHandlerFactory() being called.
• felix.fragment.validation - Determines if installing unsupported fragment bundles throws an exception or logs a warning. Possible values are "exception" or "warning". The default value is "exception".

The Felix framework installation contains a default conf/config.properties file for automatically starting the shell-related bundles.

...

Migrating from Earlier Versions

Apache Felix Framework 1.4.0 introduced some configuration property changes. This section describes the differences from older versions of the framework.

• Removed
  • felix.embedded.execution - No longer needed, since the framework now never calls System.exit(); the creator of the framework is now always responsible for exiting the VM.
  • felix.strict.osgi - No longer needed, since all non-specification features have been removed.
  • felix.cache.dir - No longer needed, since Felix no longer uses bundle cache profiles for saving sets of bundles.
  • felix.cache.profile - No longer needed, since Felix no longer uses bundle cache profiles for saving sets of bundles.
• Renamed
  • felix.cache.profiledir - The equivalent of this property is now named org.osgi.framework.storage.
  • felix.startlevel.framework - The equivalent of this property is now named org.osgi.framework.startlevel.beginning.
• Introduced
  • org.osgi.framework.system.packages.extra - New property, as described above, added to align with standard framework API.
  • org.osgi.framework.storage.clean - New property, as described above, added to align with standard framework API.
  • felix.cache.rootdir - Introduced as a result of removing bundle profiles to help resolve relative bundle cache directories.
  • felix.fragment.validation - Introduced to control fragment validation, since the default behavior introduced in 1.2.0 of throwing an exception for fragments using unsupported features was causing issues for some users.

For the most part, these changes are minor and previous behavior achieved from older configuration properties is either easily attained with the new properties or no longer necessaryoverride system properties. For more information about available configuration properties, refer to the Apache Felix Framework Configuration Properties document. The Felix framework distribution contains a default conf/config.properties.

System Property

...

Substitution

It is possible to use system properties to specify the values of properties in the conf/config.properties file. This is achieved through system property substitution, which is instigated by using ${<property>} syntax, where <property> is the name of a system property to substitute. When such a property value is retrieved by a bundle, the system property value will be substituted into the bundle property value the properties file is read, any such property values are substituted as appropriate. It is possible to have nested system property substitution, in which case the inner-most property is substituted first, then the next inner most, until reaching the outer most.

...

Some bundles use properties to configure certain aspects of their behavior. As an example, the default URL for the cd command of the shell service can be specified using the property felix.shell.baseurl. It is a good idea, when implementing bundles, to parameterize them with properties where appropriate. To learn about the configuration options for specific bundles, refer to the documentation that accompanies them.

Bundle properties are may also be defined in the conf/config.properties property file. Any property placed in this file will be accessible via BundleContext.getProperty() at run time. The property file uses the standard Java property file syntax (i.e., attribute-value pairs). For information on changing the default location of this file, refer to the section on configuring Felix.

...