|
|
|
|
|
Following is a description on setting and getting the system properties related to the operation of the framework.
Background
System properties can be classified in four categories:
The interpreter of a Java virtual machine uses conventional system properties, which are usually listed in the documentation of the VM. Such an interpreter property is the java.class.path, which wraps the environment classpath. See the Java Language Specification for further details.
The OSGi Framework Specification in its "Environment Properties" section defines properties for the general features of the framework environment, such as language, vendor, version, operating system, and processor.
The framework uses properties to tune its boot and runtime behavior. You set them before you start the framework. The framework properties are subject of this document.
The bundles in the OSGi Runtime might also use system properties to set parameters important for their operation. Usually, when a bundle's system property is modified, the bundle should be restarted for the change to take place.
Setting system properties
Prior to framework startup
The following methods for setting system properties are convenient for both system properties of the framework and system properties of the active bundles. In addition, the state of system properties will survive across framework restarts.
Windows:
set VM_ARGS=%VM_ARGS% -Djavax.net.ssl.keyStore=D:/develop/my_security/https/server.p12
set VM_ARGS=%VM_ARGS% -Djavax.net.ssl.keyStorePassword=server
set FWLAZY=true
Linux:
export VM_ARGS="$VM_ARGS -Djavax.net.ssl.keyStore=D:/develop/my_security/https/server.p12"
export VM_ARGS="$VM_ARGS -Djavax.net.ssl.keyStorePassword=server"
export FWLAZY=true
For more information on the environment variables for the OSGi Runtime refer to the Environment variables section.
The properties specified as values of the environment variables are with highest priority, that is, they overwrite the ones specified in another manner (for example in a property files).
mbs.output = remote
mbs.output.remote.host = 192.168.244.18
mbs.output.remote.port = 2020
A property file should not end with a comment ("//").
The default property files are bin/vms/common.prsand bin/vms/<vm_name>/default.prs in this directory and you can use them to set system properties on your own. If common.prs and default.prs contain the same property definitions, those from default.prs are with higher priority.
You can use custom property files as supplements to the OSGi Runtime's default property files. Specify the paths to such property files as value of the EXTPRS environment variable (e.g. in an auto* script). Separate each path with semi-colons (";"). For example:
Windows:
set EXTPRS=%EXTPRS%;myproperties1.prs;myproperties2.prs
Linux:
export EXTPRS=$EXTPRS;myproperties1.prs;myproperties2.prs
If the default property files common.prs or default.prs and some of your extending property files contain the same properties, the framework will use those from your file.
In case you will use one or more property files other than default.prs and common.prs and supplements of them, specify the paths to such property files as value of the FWPRS environment variable (in an auto* script or in the server_common script). Separate each path with semi-colons (";"). For example:
Windows:
set FWPRS=myproperties1.prs;myproperties2.prs
Linux:
export FWPRS=myproperties1.prs;myproperties2.prs
In general, the properties from the files placed at a forward position in EXTPRS or FWPRS have higher priority.
A system property file might also be available in lib/framework/serverXxx.jar which contains the framework of the OSGi Runtime - the file will be retrieved from there if the framework has not found the property files at the specified location.
import java.util.Properties;
public class Config {
static final String[] PROPERTIES = {
"mbs.boot.bootfile", "boot.ini",
"mbs.bundles.base", "../../../bundles/",
"my.property", "myvalue"
};
public static void load(Properties systemProps) {
for (int i = 0; i < Config.PROPERTIES.length; i+=2) {
String propertyName = Config.PROPERTIES[i];
String value = Config.PROPERTIES[i+1];
if (propertyName != null && propertyName.trim().length() > 0) {
systemProps.put(propertyName.trim(), value.trim());
System.out.println("Setting system property " + propertyName + " with value " + value + ".");
}
}
}
}
At framework runtime
This approach is convenient for system properties of bundles. If system properties of an active bundle are changed, restart this bundles for the changes to apply. The state of the properties specified in this way will be lost on a framework restart. To modify a system property at runtime, in the framework's text console (command prompt or Telnet) invoke the set command:
set mbs.output=remote
set mbs.output.remote.host=192.168.244.18
set mbs.output.remote.port=2020
Aggregating system property values
As previously discussed above, in the case of setting system properties in property files, the value of a system property being present across several files is taken from the last file in the relevant path setting. To aggregate the values of a certain property defined in more than one property file, add the property name to the system property mbs.sysPropsToUnite separating it with "," from the other entries. By default, the values of the mbs.syspackages, org.osgi.framework.system.packages and org.osgi.framework.bootdelegation are aggregated. To have effect the mbs.sysPropsToUnite system property has to be added to the command line for OSGi framework startup. If you are using the bin/vms/<vm_name>/server script to start the OSGi Runtime, this can be done by adding the following to the VM_ARGS environment variable.
-Dmbs.sysPropsToUnite=<system properties to be aggregated>
Getting system properties
You can view system properties by using:
set mbs.output