|
|
|
|
|
The Framework Validator bundle provides a self-validation environment to your OSGi framework runtime.
Overview
The Framework Validator bundle provides a self-validation environment to your OSGi framework runtime – it provides the means to check the initial state of the Framework and is able to use an extender pattern to find out which bundles provide self-validating code, loading and executing their code through the bundles' class loaders. It then returns a list of errors and/or status messages.
Bundles can provide their own self-validation code by implementing the com.prosyst.mbs.services.validator.BundleSelfValidator interface. To make the Framework Validator aware of themselves they need to specify the class holding the implementation in their manifest files via the Validator-Class manifest header.
Other bundles running on the framework may include this self-validating code in fragments which are specified it in their manifest with the following manifest header: Validator-Fragment. The Framework Validator is able to recognize this special manifest header for the fragment name, and on encountering it will install the specified bundle fragment before executing the self-validation code. After self-validation is executed, the validator bundle will uninstall the fragment.
It is also possible to execute self-validation process as part of framework startup process. In this case, the validator bundle will also uninstall itself after validation is complete.
The Framework Validator is able to read external configuration files that describe which bundles are available in the framework after startup, their status and registered services. The Framework Validator is also able to verify all information in this configuration file against the current OSGi Runtime instance and notify mBSA if there is a mismatch between both.
Util Validator New Functionality and Changes in XML
The validator bundle has been updated to provide the options to:
New <services> Tag
The new version of the XML descriptor includes a new tag named '<services>'. This tag wraps the service description for a bundle. If the tag is not present, the Validator ignores the service status and information when validating a bundle.
New 'exact.match' Attribute
The '<services>' tag has an attribute named "exact.match". If the value for this attribute is "true", then the bundle described will pass validation if and only it has registered the same services as described in the Validator XML, and it has no other services registered. If "exact.match" is "false", then the bundle will pass validation as long as the services described in the XML are present, even if the bundle has also registered other services. Default value is "false". If "exact.match" is set to "true", and no services are described under the '<services>' section, the bundle will pass validation only if it does not have any services registered.
Example
Example for a bundle definition:
<bundle symname="com.bosch.bundle" state="active" version="1.0.0">
<services exact.match="true">
<service class="com.bosch.bundle.Service"/>
</services>
</bundle>
The bundle "com.bosch.bundle" will pass validation if and only if it has one service registered under the "com.bosch.bundle.Service" interface
Backward Compatibility
Since it required changes to both the Validator XML format, and the Validator behavior, the Validator bundle has been made to provide options for backward compatibility and support of the previous format for its XML descriptor.
If the system property "com.prosyst.mbs.services.validator.v1" is set with value "true", the validator acts as if the '<services>' section is always present and the attribute "exact.match" is set to "true".