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

Runtime Design

Thomas Diesler edited this page Oct 9, 2013 · 4 revisions

The Gravia Runtime comes in two flavours

  • Embedded Runtime
  • OSGi Runtime

The Embedded Runtime is used with target containers that do not natively support OSGi (e.g. Tomcat, Wildfly). The OSGi Runtime is used on OSGi containers (e.g. Apache Felix, Equinox)

Embedded Runtime

gravia-embedded-runtime

The Gravia Runtime supports a Modules and Services API that should look familiar to those who know OSGi Bundles and Services. It is however no replacement of an OSGi Framework, instead it provides a subset of OSGi functionality in its own portable API.

Using the Gravia API allows projects to take advantage of the successful Dynamic Services API from OSGi including Declarative Services and Configuration Admin without the OSGi modularity layer.

Configurable components that use Declarative Services annotations will work in any target environment including Tomcat, WildFly or a plain JUnit test.

Internally, Gravia uses the unmodified implementations of Felix SCR, Config Admin, Metatype and Log Service. The internal dependency on the OSGi API is bridged to the Gravia Modules and Services API.

Application code would use the Gravia Runtime API only and hence be portable across various target environments.

OSGi Runtime

gravia-osgi-runtime

When running in an OSGi environment, Gravia provides a simple bridging API that maps Gravia Modules to OSGi Bundles and Gravia Services to OSGi Services. It is therefore possible to gradually migrate application code away from OSGi, but keep running in an OSGi Framework. When migration is complete, the application would automatically work in non-OSGi environments too. Gravia maintains the API semantics across target environments.