What's new in Apache Karaf 4.3.0

Apache Karaf 4.3.0 is an important milestone for the project and is the new main releases cycle.

This release brings a lot of improvements, fixes, and new features.


This is not directly related to Apache Karaf 4.3.0, and I will do a blog specifically about Winegrower.

However, Winegrower is a new great asset in the Karaf ecosystem. It provides a very elegant programming model with a simple/flat classloader model. It’s a concrete alternative to Spring Boot:

  • full support of OSGi R7 annotations and programming model without the classloader complexity. It means that you can use your existing bundles in Winegrower.
  • As Winegrower use an unique classloader, you can directly use pure jar (not necessary bundles) without any MANIFEST header
  • the cepages is equivalent of spring boot starter, allowing to add turnkey features that you can use in your application
  • extensions

I will publish a blog about Winegrower soon.


To simplify the dependencies management when you create your runtime or application for Karaf, you now have a BoM providing the dependency versions for Karaf and used dependencies.

You don’t have to bother about dependencies version anymore, you can use the dependency management.

For instance, in your project, you can use the Karaf BoM like this:

    <dependencyManagement>        <dependencies>            <dependency>                <groupId>org.apache.karaf</groupId>                <artifactId>karaf-bom</artifactId>                <version>4.3.0</version>                <type>pom</type>                <scope>import</scope>            </dependency>        </dependencies>    </dependencyManagement>

Then, you can directly use the Karaf dependencies without defining the version, for instance:

   <dependencies>      ...      <dependency>         <groupId>org.apache.karaf</groupId>         <artifactId>org.apache.karaf.util</artifactId>      </dependency>      ...   </dependencies>


Apache Karaf 4.3.0 brings OSGi R7, meaning that you can now use the “new” annotations.

Instead of defining the OSGi header statements in the maven-bundle-plugin configuration or osgi.bnd file, you can “describe” your bundle by annotations.
It’s actually easier, sync with your code and more compact.

For instance, you can define an exported package directly on package-info.java like like this:

@org.osgi.annotation.bundle.Export@org.osgi.annotation.versioning.Version("1.0")package org.apache.karaf.examples.bundle.common;

It’s pretty similar to define the activator of a bundle:

import org.osgi.annotation.bundle.Header;import org.osgi.framework.BundleActivator;import org.osgi.framework.BundleContext;import org.osgi.framework.Constants;import org.osgi.framework.ServiceRegistration;@Header(name = Constants.BUNDLE_ACTIVATOR, value = "${@class}")public class Activator implements BundleActivator {  ...}

It means that you just have to define the maven-bundle-plugin, without any configuration, just like this:

    <build>        <plugins>            <plugin>                <groupId>org.apache.felix</groupId>                <artifactId>maven-bundle-plugin</artifactId>            </plugin>        </plugins>    </build>

Docker, system properties, env variables

You probably know that it’s very easy to package Karaf as a docker image, either building your own distribution or using an official Karaf Docker image (https://hub.docker.com/r/apache/karaf/tags).

However, when you use Docker, it’s not convenient to try to change configuration files in a Docker container.
In Docker, it’s easier to populate or overwrite configuration via system properties or env variables.

Regarding this, Karaf 4.3.0 brings a new configuration plugin features. Thanks to this new feature, you can overwrite any configuration using either environment variables or system properties.

You can use PID_PROPERTY=VALUE syntax for environment variable and pid.property=value for system properties.

For instance, the following statement will override value of sshPort (by default, defined in etc/org.apache.karaf.shell.cfg):

# environment variableexport ORG_APACHE_KARAF_SHELL_SSHPORT=8102
# system property-Dorg.apache.karaf.shell.sshPort=8102

You can overwrite any configuration using this mechanism.

It’s possible to “append” a new value based on the content of a configuration property. For instance, you want to add a new features repository to the default value (define the etc/org.apache.karaf.features.cfg config file featuresRepositories property. You can use the following env variable:

export ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES='${featuresRepositories},mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.5.0/xml/features'

It means that Karaf will take value of featuresRepositories property (default defined in the etc/org.apache.karaf.features.cfg configuration file) and add mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.5.0/xml/features.

It’s pretty convenient to use with docker run. For instance, you can easily do:

$ docker run -env ORG_APACHE_KARAF_SHELL_SSHPORT=8102 --name my-karaf karaf

Json configuration and configurator

By default, Karaf uses properties format in cfg file.

Karaf 4.3.0 adds support of JSON configuration format. It means that you can create a configuration like my.json in the etc folder, containing, for example:


It supports “typed” properties, meaning that you can define:

"an_int_array:int[]" : [2, 3, 4],
"an_Integer_collection:Collection<Integer>" : [2, 3, 4],
"complex": {
"a" : 1,
"b" : "two"

Of course, this configuration format can be used directly in features file (in the config element).

It also means that Karaf 4.3.x supports Configurator in bundles. It means that you can now ship a json configuration as part of your bundle (in OSGI-INF/configurator folder). You can take a look on the Configurator specification for details.

Features (requirements and capabilities)

We started a cleanup process on features, both features resolver and features definition.

If a simple flat features resolver (optional but more predictable and avoiding refreshes).
We are also preparing cleanup and new features XML, especially for specs (easier to use).

However, Karaf 4.3.0 already brings some improvements on the existing features.

A good example is to decouple from features from pax-web, allowing users to decide if they want to use pax-web or felix-http service for instance.

For instance, it’s the case of webconsole. Previously installing webconsole feature installed Pax Web. And so, it was not easy (almost impossible) to use the WebConsole with Felix HTTP instead of Pax Web.

So, now, it’s “decoupled” and based on capability and requirement.

Meaning that you can first install felix-http feature and then the webconsole feature, that will use Felix HTTP.

Coming features

As said, we are working on the features area. For the next Karaf releases, you can expect:

  • new optional simple feature resolver
  • better features definition (low coupled)
  • new features (coming partly from ServiceMix)
  • features description in JSON format (in addition of XML)

We are also working on new tools, a Karaf launcher (using @KarafApplication annotation), and expand the support of more programming frameworks (spring boot, microprofile/cdi, …).

I started a discussion thread on the mailing list to already discuss about the Karaf 5 roadmap.


Popular posts from this blog

My first days at Huawei

Apache Karaf and log4j2 appenders

What's new in Apache Karaf 4.2.11 ?