Digital Experience Manager OSGi architecture

  Written by The Jahia Team
 
Developers
   Estimated reading time:

In this section of the documentation we present high-level views of the architecture, flows and class loader hierarchies of Digital Experience Manager OSGi integration.

Architecture overview

Digital Experience Manager has integrated into version 7.0 an OSGi framework developed by the Apache Foundation called Felix. The goal of this integration was to offer the possibility for module developers to use OSGi to package their modules, therefore benefiting from the clean isolation that this technology offers. Over time, it is expected that more and more parts of the Digital Experience Manager core code will migrate into modules, therefore expanding the usage of OSGi bundles throughout the application. This process will take some time and will clearly happen over the course of several versions but should not affect module developers significantly as their bundles will already be packaged using OSGi bundles.

image006.jpg

Inside the OSGi framework, all the modules are now deployed as bundles, but Digital Experience Manager also embeds a service that transforms a legacy WAR Digital Experience Manager module into an OSGi bundle at deployment time.

Since 7.2, all the OSGi bundles are managed by Karaf, an OSGi bundle container that is still working with Felix, but bring new functionalities as support of features or module management in cluster.

Other system bundles include the Felix Web Console and the Karaf Command Line shell, which are two low-level administration tools that are quite useful to access the OSGi internal runtime.

The Digital Experience Manager administration is now implemented using OSGi modules and therefore now also lives inside the OSGi framework.

Request flow

The request flow was modified with the introduction of the OSGi framework to address the following requirements:

  • be able to serve resources directly from an OSGi bundle, compiling JSPs that are located inside bundles and serving images directly from the JAR
  • integrating other OSGi Http services such as the Felix Web console

The graph below shows how the different software components are involved in request processing. Basically on the left side this is the legacy request flow processing before OSGi introduction and in the middle the Felix Http Bridge relays the requests through the OSGi Http service to integrate with bundles that register servlets inside the Http Service. The Digital Experience Manager OSGi extender is a bundle that listens to bundle events and is responsible for registering all the different resources of a bundle into the Http Service. On the right Digital Experience Manager also exposes another OSGi proxy servlet to expose services such as the Felix Web Console available at the Digital Experience Manager http://localhost:8080/tools URL.

5.3 Class loader graph

In this section, we illustrate what the class-loading graph looks like in a typical Digital Experience Manager installation. By default, the server is integrated with the Apache Tomcat servlet container, and the graph below includes the Tomcat class loaders.

As we can see the Jahia Webapp is the main application class loader, but below we see that the graph no longer looks like a tree and OSGI class loaders may access different class loaders depending on their declared dependencies.

If you’re interested in learning more about the Tomcat class loader, you can find the related documentation here: http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html