Skip to content
This repository has been archived by the owner on Jul 12, 2024. It is now read-only.

OSGi Integration

Jump to bottom
Thomas Diesler edited this page Jan 27, 2014 · 10 revisions

Preparing the Framework

Gravia provides a patch for for Karaf as a Maven artefact

<dependency>
	<groupId>org.jboss.gravia</groupId>
	<artifactId>gravia-container-tomcat-patch</artifactId>
	<type>zip</type>
</dependency>

It contains a number of config files and bundles.

Preparing a Bundle

Gravia works with already resolved Bundles that have a valid ClassLoader. In this case with the ClassLoader provided by the Framework.

A Gravia runtime module it must be associated with a valid resource. The minimum criteria is that it has a resource identity (for details see defining a module). The resource identity can be given as a manifest header like this:

Gravia-Identity: org.acme.foo;version=1.0.0

or, in case you want to reuse the bundle symbolic name and version, like this

Gravia-Enabled: true

In case a resource identity is not given, which would be the case for a 3rd party OSGi Bundle for which you do not control the source code, the resource identity will be derived from the bundle symbolic name and version. Every OSGi Bundle is also visible through the Gravia Module API. You can work with the Gravia services API to access OSGi services and vice versa. However, because of their unportable nature, OSGi APIs are generally not supported. The Gravia APIs work in all supported target containers. The OSGi APIs only work in the OSGi container.

To make a portable Gravia artefact from a Bundle, you would want to replace all usages of OSGi API with the Gravia equivalent. In most cases this will be a matter of changing the import package statement from org.osgi.framework to org.jboss.gravia. OSGi functionality that breaks portability because it is not supported in other target containers includes

  • Embedded jars
  • Fragments
  • StartLevel
  • etc.

Low level dynamic services, declarative services that are configurable and the http service are supported. The recommended programming model is to use declarative services.

Gravia currently still exposes some original APIs for the above services. In future we will likely provide a Gravia equivalent for these too.

Activating the Module

The portable way for Gravia module activation is to use a ModuleActivator. In order for this to tie correctly into the bundle lifecycle it must be called from the BundleActivator. Gravia provides a ModuleActivatorBridge that calls the defined ModuleActivator reflectively

In a manifest this can be defined like this

Bundle-Activator: org.jboss.gravia.runtime.ModuleActivatorBridge
Module-Activator: org.acme.foo.Activator

In the ModuleActivator you can register/lookup services, work with DS defined components, etc.

Clone this wiki locally