An analysis of the principles of OSGi Bundle convert plug-in

1. Introduction

Ordinary Web applications are converted to OSGi applications, often encountering a nonstandard case of the jars that are dependent on the application, which may only comply with some of the OSGi specifications, or even manifest information is empty. This situation is simply not possible to use this non-standard jar as a bundle in OSGi applications, so it is necessary to convert this non-standard jar into a bundle that complies with the OSGI specification. In addition to the warehouse managed by MAVEN, because different developers have different understanding of the specification, there are various specifications or nonstandard jars in the warehouse, if we can transform the jar in the MAVEN warehouse into the standard Bundle,maven warehouse, we will convert it to the corresponding OSGi. bundle warehouses, for non-OSGi applications can also be easy to use the Maven warehouse, ordinary Web applications can also be smooth switch to the OSGI environment.

2. Ways to convert bundle

To convert non-standard jars into OSGi Bundle, the core is how to rewrite the Import-package and export-package content in Bundle. The way to convert the Bunlde can be divided into 3 ways: 1. Fixed version mode conversion; 2. Non-fixed version conversion; 3. Fixed and non-fixed versions of mixed-mode conversions;

2.1 Fixed version mode

The conversion is mainly based on the jar corresponding to the pom dependency tree (mvn dependency:tree), and in the case of an indeterminate version of the Pom, it is necessary to rely on the bundle module Pom's dependent quorum to force the selection of a version, which eventually translates to a good bundle Import-package and export-package are fixed versions; a fixed version conversion is somewhat similar to a jar version strong dependency in Maven, and this bundle must import the specified fixed version bundle. This is done so that each bundle dependent environment that is converted is a separate collection, and there is no conflict between the collections.

2.2 Non-fixed version mode

Package and import package information are converted according to the *.class in the jar file, and the bundle after the final conversion does not specify the Import-package version and the export-package version ; This situation is now commonly used not specified version range or no version package, especially without version package, in the OSGi environment, will use verison>=0.0.0 way to choose Bundle, as long as the latest version is available, Replaces the new environment with the latest version.

2.3 Mixed use of fixed and unfixed versions

Depending on the pom dependency tree conversion, an Bunlde version is encountered and the Import-package and Export-package will have a fixed-dependency version, no version information, or version interval in the final conversion. Cases:

Import-package:org.apache.commons.collections.comparators;version= "[3.2.0,3.2.0]
", Org.apache.commons.collections.keyvalue;version= "[3.2.0,3.2.0]
", org.apache.commons.collections.list; Version= "[3.0.0,3.2.0]
", org.apache.commons.collections.set;version= "[3.0.0,3.2.0]"
, Org.apache.commons.logging

Bundle for 3.maven-bundle-plugin plug-in conversions

Typically, the development of OSGi environments is relatively complex, and it can be seen from the above that the conversion of bundle is more complex, so the industry has provided such a MAVEN plug-in maven-bundle-plugin (see resources [1]) to do this. The conversion method is exactly the same as the combination of fixed and unfixed versions.

In fact, Maven-bundle-plugin is using the BND plug-in to complete the conversion of bundle. This MAVEN plugin mainly uses ASM parsing for bundle conversion, reads the byte code information of the class file in the jar file, resolves the package and import package information in the class file, The final analysis rewrites the import-package and export-package of MANIFEST.MF.

This pattern is used in a stand-alone project and may not be a big problem, but the bundle of this MAVEN plugin does not handle several special scenarios very well, and the following is a detailed analysis of the bundle problem after conversion using this conversion pattern from 2 dependencies of OSGi bundle.

3.1 Conversion to Fixed version dependency

(Figure 1)

As shown in Figure 1, if it is a multiple-person, multisectoral, collaborative development environment, it is likely that different bundle are developed by different development roles, when BundleA1.0.0 requires that BundleA1 be used 1.0.1,bundleb 1.0.0 requires that BundleA1 1.0.0 be used. However, the BundleA1 they rely on are conflicting, so it is necessary to specify that Bundlea and Bundleb rely on their respective versions of BundleA1 to resolve, at which point 2 BundleA1 exist in an application environment and provide services simultaneously, Fixed-version bundle dependencies are a good way to resolve conflict problems. In this case, however, the simultaneous presence of Bundlea and Bundleb can cause communication problems between the 2 bundle. This is because the same class (the class in BundleA1) makes a classcastexception exception because of the ClassLoader difference in the type conversion. In section 4th, "Improvements to Plug-ins", we will describe in detail how to troubleshoot fixed version patterns.