OSGI DEMYSTIFIED, UNRAVELING JAVA AND OSGI CLASS LOADER

A compelling and practical model of a Java framework called Open Services Gateway Initiative (OSGi) is used for creating and distributing modular software applications and libraries. Let's first understand what OSGi (Open Service Gateway Initiative) is and its fundamental concepts.

What is OSGi?

A Java framework called OSGi (Open Service Gateway Initiative) is used for creating and deploying modular software applications and libraries. Many applications, including Eclipse Equinox, Apache Felix, and others, use the OSGi framework's dynamic modular architecture.

Bundle

The OSGi bundle is nothing more than a JAR of Java classes that contains a manifest. MF file lists the names of the types that are exported and imported as well as the version and name of the bundle. A bundle defines the module idea. The OSGi development unit is a bundle. An OSGi application typically consists of several bundles. Bundles can consistently share packages and hide packages.

Each bundle is a jar during the deployment stage. Bundle jars differ fundamentally from regular jars because they contain OSGi-specific manifest definitions and some OSGi-specific classes. The module layer declares which packages in the JAR file are visible to outsiders and which external packages the bundle depends on through the manifest—MF metadata file.

• Bundle-SymbolicName: As the only definition that must be included in the MANIFEST file, this term defines the bundle's distinctive name within the OSGi ecosystem. It is generally defined as the base package name of the pile by convention because this definition should be singular.
• Bundle-Description: A description of the bundle's "raison d'être."
• Bundle-ManifestVersion: The bundle's manifest version.
• Bundle-Version: OSGi bundle version- patch, minor and major versions
• Bundle-Activator: This class is utilized to manage the bundle's life cycle. OSGi uses this class to start or stop the bundle.
• Export-Package: Packages intended to be used by other bundles are defined in this section under export-package. 
• Import-Package: This offers the packages required for the current bundle's execution.

Service

Services are utilized to facilitate the interaction amongst bundles. The Java interface specifies services. Bundles may use this interface and submit the service for registration with the Service Registry. The registry is where users of the service may locate it.

There are two methods for publishing and looking up OSGi services.

Bundle Activator

Printing "Hello world" is a service offered by Bundle A. Therefore, the service must be registered to be exposed to other bundles. Here, we use Bundle Activator to record the service. Then, when bundle B requests the service, that bundle's bundle activator should use it.

Declarative service

An alternative to OSGi services APIs is presented here. This implementation is based on annotations. This lessens OSGi's complexity. Data about declarative services are kept in OSGI-INF/serviceComponents.xml.

The OSGi structure offers the required controls for managing the life cycle of the bundles.

Installed

This state denotes successful completion of the installation step. In this case, neither the class loading nor the dependency analysis is performed. Only necessary steps, like setting bundle properties and analyzing its Manifest file, are carried out.

Resolved

When OSGi resolves, satisfies, and performs class loading operations for all of a bundle's dependencies, the bundle is found in the state of "RESOLVED." This is the condition that occurs both before and after stopping.

Start‍

 When the "start" method of the bundle's Activator is called, the bundle is in the state of "starting," and it has not yet been determined whether it has been successful or unsuccessful.

Active 

The bundle has been successfully started and is currently operating, proving that the Activator's "start" method was successful.

Stopping

When the "stop" method of the bundle's Activator is called, the bundle is in this state but has not yet reached a successful or unsuccessful conclusion.

Uninstalled

When a bundle is uninstalled from the system, it is in this state. There is not a change of state in this instance. The component needs to be reinstalled.

Java Class Loaders

A Class Loader is just another Java class that loads class files in Java. The java compiler converts the.java files the code we write in Java into .class files. The bytecodes for the code we wrote are stored in these class files, and the JVM uses these bytecodes to run the program.

Delegation

forwards class-loading requests to the parent class loader and only loads the requested class if the parent cannot locate or load the requested class.

Visibility

The parent class loader cannot see the classes loaded by the child class loader, but the child class loader can see all the classes loaded by the parent class loader.

Uniqueness

enables a class to be loaded exactly once, essentially accomplished through delegation, and ensures that a child Class Loader doesn't reload a class that the parent has already loaded.

Bootstrap

It is the parent of all Java class loaders and is in charge of loading the common JDK class files from rt.jar. (JRE/lib/rt.jar)

Extension

 When a class is loaded, the system first tries to load it from its parent, Bootstrap, but if that doesn't work, it loads the class from any directory or the JRE/lib/ext directory listed by the system parameter java.ext.dirs.

System

Application-specific classes are loaded by the system from the $CLASSPATH environment variable.

OSGi Classloading

As I already mentioned, the only class loaders available for Java are parent and child class loaders. And the parents let their kids enroll in any classes they know about. In contrast to those, OSGi class loaders adhere to a peer-based process. They only use peer jar files that expose classes in the version their jar file wants to use, and they only expose the classes that the peer jar file wants to expose.

There must be no jar files containing OSGi bundles on the standard Java class path. Instead, they are loaded by making an OSGi org.OSGi.framework.launch.Framework object and then loading the bundle jar files with Framework.getBundleContext().installBundle(path). A unique instance of an OSGi-specific subclass of the Java .lang.Class loader is used to load each of the "installed" bundles.

Each OSGi bundle has a unique mapping table that identifies the classloader in charge of supplying the current bundle with classes from a particular package. When the pile is initially loaded and in the resolved state, this is populated. Therefore, the Framework first creates a Bundle object to represent the jar file when a bundle's jar file is loaded. That object then creates a classloader that is a child of an OSGi environment classloader.

Like traditional Java, the bundle's classloaders pass requests for classes in various packages up to the parent classloader. This indicates that all bundles can access core Java classes, typically loaded from the Bootstrap class loader. Requests are not forwarded to the parent for any other packages. Instead, the classloader will use the bundle-specific mapper table to resolve classes.

As a result, classes in a new bundle are, by default, unable to see any categories from the Java JDK or those in a typical Java application classpath ($CLASSPATH). Instead, the Import-Package declaration, which instructs the Framework to copy the entry from the shared map of all possible packages into the bundle-specific map of imported packages, should be used by the bundle to see those.

We can now practice on an OSGi failure to use the newly acquired knowledge. To learn more about it, get in contact with Cogent University.