DX OSGi Implementation
OSGi Framework startup
The OSGi framework is started once DX spring context is instantiated. In turn, FrameworkService initializes Karaf instance which registers all the bundles that will initially be started and made available to all deployed bundles. Of particular note, FrameworkService loads its configuration from the felix-framework.properties file which contains important settings such as which packages are made available to all bundles.
OSGi Servlet Bridge
The OSGi servlet bridge consists of two parts, a proxy servlet that is mapped as a servlet in the
WEB-INF/web.xml file of the Digital Experience Manager web application and then the actual bridge that will make it possible to call “regular” servlet inside the OSGi framework.
Digital Experience Manager Module Extender
The core of the module integration is in the
jahia/bundles/jahiamodule-extender project. Here the Activator class is the starting point, that registers the bundle listeners to listen for the deployment and undeployment of bundles and does all the registration work inside Digital Experience Manager. This is where most of the OSGi “magic” is happening, including the registration and dispatching to JSPs.
We can have both system bundles that will be handled by Karaf (such as Karaf extensions) and DX bundles (common DX modules).
We are relaying on Karaf for system bundle. All the system bundles are in the Karaf folder, by default located in
digital-factory-data/karaf. From here you can use all the Karaf framework to deploy any bundle / feature / kar file. See more information here:
DX has a also watched directory located in digital-factory-data/modules that contains all dx installed bundles
OSGi and Digital Experience Manager Module States
Bundle life cycle
With the installation of a bundle in the OSGi runtime the bundle is persisted in a local bundle cache. The OSGi runtime then tries to resolve all dependencies of the bundle.
If all required dependencies are resolved, the bundle is in the
RESOLVED status otherwise it is in the
If several bundles exist which would satisfy the dependency, then the bundle with the highest version is used. If the versions are the same, then the bundle with the lowest install ID will be used (the bundle gets a unique identifier assigned by the framework during the installation). If the bundle is started, its status is
STARTING. Afterwards it gets the
This life cycle is depicted in the following graphic:
Digital Experience Manager extends the default OSGi lifecycle states to add intermediary states that detail the state in which a module is. You can find the description of these states in the following table.
|Bundle is not installed
|Bundle is installed, but dependencies haven’t been resolved
|Bundle is installed and all dependencies have been resolved
|Bundle is started but it depends on other Jahia modules for content definitions [removed in DX 188.8.131.52]
|Bundle is started and all its content definitions have been parsed [removed in DX 184.108.40.206]
|Bundle was installed, but not started
|Bundle was updated
|Bundle was stopped
|Bundle is stopping
|Bundle is starting
|Bundle is waiting to be started, waiting for another module to be started [removed in DX 220.127.116.11]
|Bundle is waiting to import its content, waiting for a dependency to import its content
|An error occurred during Jahia module start [removed in DX 18.104.22.168]
|Bundle is fully started and available
|Bundle is started but is waiting for spring context to be available [since DX 22.214.171.124]
|Module failed to start due to an error creating module's Spring context [since DX 126.96.36.199]
|The DX required version of the module is incompatible with the current one
|Bundle cannot start due to definitions error
|Module failed to start due to an error compiling included business rules (Drools) [since DX 188.8.131.52]