This document contains several optimization issues about the operation of the framework.
Contents:
For correct and fast startup of the framework, the Package Manager writes manifest information about resolved bundles, i.e. bundle activator, symbolic name, package importer-exporter relations, etc., in two files within the persistent storage.
The first one, resolve.inf, keeps resolving information about "system management" bundles - the bundles installed by the Boot module (by default, those included in the boot INI file) and meant to be always present at startup. This file is generated when the storage is created for the first time, and is processed at each startup. To change the name of the system resolving file, use the mbs.resolveinfo.file system property.
The second one, appresolve.inf, keeps resolving information about "application" bundles - the bundles installed after the boot bundles. This file is created at framework exit and is processed only if there is a change in the runtime bundle configuration, i.e. a bundle is installed, uninstalled or updated. The use of the application resolving file is activated with the mbs.resolveinfo.useappfile system property (true by default), and the name of the file can be changed with the mbs.appresolveinfo.file system property.
Separating the resolving information in two files examined at different events provides optimized startup with processing only the important system dependencies and saves processing of application dependencies. In this way, the startup time does not depend on the number of installed application bundles. In case, the use of application resolving file is not active, all resolving information will be placed in the system resolving file and will be processed at startup.
Another means for achieving correct startup is the "mark" directory, created in the storage at runtime. In case the framework has been abnormally shut down, during the subsequent startup the Package Manager checks if the "mark" directory exists. If it is available, the framework ignores the information from the resolving files and traverses again the bundle manifests in the storage.
The java.net.URLStreamHandler associated with the framework persistent storage, is made public as required by the OSGi Service Platform Core Specification. Bundles can construct URLs to stored bundle entries - own and of other bundles. For example, a bundle can save persistently the URL to some of its resources and on restart to read it and open a stream to access the resource.
Bundle entry URLs can be retrieved in either of the following ways:
new java.net.URL(String spec) org.osgi.framework.Bundle object
getResource and getResources methods. The framework searches for resources in the class space of the bundle, which should be RESOLVED. The search operation will involve imported packages, required bundles, bundle classpath and fragments.getEntry method. The framework searches for entries in the raw bundle JAR file. findEntries method. The framework searches for entries in the bundle JAR file and in the bundle fragments. Bundle entry URLs have following the syntax:
storage:<bundle_id>^<ver>:<index>/<file_name>
where:
When started with security, the framework is capable of assigning internally a special type of permission to bundles - com.prosyst.mbs.impl.framework.module.security.ExclusiveFilePermission. This permission is used to enable a bundle to access (read and write) data outside the persistent storage - the bundle receives access to the entire file system except to the storage. By default, the bundle has a FilePermission to write in its private storage area.
The ExclusiveFilePermisisons for bundles can be turned on by setting the mbs.security.fileaccess system property to true.
Note that this permission should be not be used by bundles for security checks - it is intended only for internal use by the framework.
For faster startup, the framework can be configured to define the ProSyst Security Manager in the JVM (via a call to the setSecurityManager method of the System class) after all bundles up to a specific start level are started. The threshold bundle start level is configured with the mbs.sm.delayedSet.startlevel system property.
The framework supports several runtime "modes" regarding signed bundles and related permission checking:
mbs.certificates system property is equal to false or there is no implementation at all). Signatures of signed bundles are not taken into account. If in this case security is on (the mbs.security system property is equal to true), permission checking common to both signed and not signed bundles will be active.mbs.certificates.strict system property to true. Again, if mbs.security is true, permission checking will be active but this time in combination with signature trust checking. The OSGi Framework Specification defines that the support of framework and boot classpath extensions is activated by setting respectively the org.osgi.supports.framework.extension and org.osgi.supports.bootclasspath.extension system properties to true. As the mBS framework manages extensions by using its Framework Loader, it accepts these properties only if the mbs.customFrameworkLoader one is true.
Another important issue on using extension bundles, is that they must be installed in the trusted storage directory of the framework specified with the system property mbs.storage.trustedRoot. By default, this is the home directory of mBS.
Depending on the purpose of certain class libraries provided by the JVM itself or by other Java software, which should be loaded by the parent class loader, the framework offers two approaches for providing those class libraries to bundles:
mbs.syspackages or org.osgi.framework.system.packages. Package names might contain wildcards (*) and should be separated with commas, similarly to the Export-Package manifest header syntax. Refer to the OSGi Core Specification Release 4 for more details.org.osgi.framework.bootdelegation system property in the similar to org.osgi.framework.system.packages. Refer to the OSGi Core Specification Release 4 for more details.