Frequently Asked Questions - OSGi

How to use the Java driver in an OSGi environment?

We have complete examples demonstrating usage of the driver in an OSGi environment; please refer to our OSGi examples repository.

How to override Guava’s version?

The driver is compatible and tested with all versions of Guava in the range [16.0.1,20).

If using Maven, you can force a more specific version by re-declaring the Guava dependency in your project, e.g.:


Make sure that your project’s manifest is importing the right version of Guava’s packages, e.g. for 19.0:


How to enable compression?

First, read our manual page on compression to understand how to enable compression for the Java driver.

OSGi projects can use both Snappy or LZ4 compression algorithms.

For Snappy, include the following Maven dependency:


For LZ4, include the following Maven dependency:


IMPORTANT: versions of LZ4 library below 1.3.0 cannot be used because they are not valid OSGi bundles.

Because compression libraries are optional runtime dependencies, most manifest generation tools (such as BND and the Maven bundle plugin) will not reference these libraries in your project’s manifest. This is correct, but could be a problem for some OSGi provisioning tools, and notably for Tycho, because it does not consider such dependencies when computing the target platform.

If you are facing provisioning issues related to compression libraries, you might need to either add them explicitly to your OSGi runtime, or explicitly reference them in your project’s manifest. With the Maven bundle plugin, this second option can be achieved with the following BND Import-Package instruction (the example below is for LZ4, but the same applies to Snappy as well):


With Tycho, another option is to explicitly declare an “extra requirement” to the compression library in the target platform definition:


Note that the requirement id is its bundle symbolic name, not its Maven artifact id.

How to use the driver shaded jar?

The driver shaded jar can be used in any OSGi application, although the same limitations explained in the manual apply.

How to get proper logs?

The driver uses SLF4j for logging.

You OSGi runtime should therefore include the SLF4J API bundle, and one valid implementation bundle, such as Logback.

For Maven-based projects, this can be achieved with the following dependencies:



Some OSGi containers might require additional configuration. Please consult their documentation for further details.

I’m getting the error: “Could not load JNR C Library”

The driver is able to perform native system calls through JNR in some cases, for example to achieve microsecond resolution when generating timestamps.

Unfortunately, some of the JNR artifacts available from Maven are not valid OSGi bundles and cannot be used in OSGi applications.

JAVA-1127 has been created to track this issue, and there is currently no simple workaround, other than “osgi-fying” the library by yourself.

Note that if you use Maven and include any JNR dependency in your pom, these will be silently ignored by Pax Exam when running integration tests, and most likely, your tests will fail with provisioning errors.

Because native calls are not available, it is also normal to see the following log lines when starting the driver:

INFO - Could not load JNR C Library, native system calls through this library will not be available
INFO - Using java.lang.System clock to generate timestamps.

I cannot use DSE Graph Fluent API inside an OSGi container

Although the dse-java-driver-graph module, containing the DSE Graph Fluent API, is available as an OSGi bundle, unfortunately the Tinkerpop library, which it depends upon, is not.

Using the Fluent API inside an OSGi container is therefore not supported at this time. As for similar cases, the only workaround is to wrap all non-OSGi libraries inside an OSGi bundle that you would have to create and maintain manually.