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.

Winegrower

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.

BoM

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>

Annotations

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:

{
"hello":"world",
"foo":"bar"
}

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

{
"port:Integer":8888,
"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.

Comments

Post a Comment

Popular posts from this blog

Exposing Apache Karaf configurations with Apache Arrow Flight

Image
This blog post shows how to use Apache Arrow and Arrow Flight in Apache Karaf runtime. The code base is available here: https://github.com/jbonofre/karaf-arrow . Apache Arrow ? Apache Arrow is composed by: The Arrow format (specification). Format implementations with different languages (C, Java, Go, Rust, ...). Extra subprojects like Flight, Flight SQL, ADBC, nanoarrow, ... Apache Arrow format is a in-memory columnar format, super efficient for scanning and iterating a large chunks of data. In traditional memory buffer, we focus on "row". Apache Arrow format "groups" data per column, which is much more efficient on modern CPUs/GPUs. The Apache Arrow format is basically a specification. We have several implementations for this specification: C C++ C# Go Java Python Ruby Rust As the purpose of this blog post is to show Apache Arrow in Apache Karaf, we will use Arrow Java. In addition, Apache Arrow also provides several...
Read more

Getting started with Apache Karaf Minho

Image
Apache Karaf Minho Apache Karaf Minho is a new runtime, completely created from scratch. The objectives are: super easy to use and run ligtning fast, including GraalVM support Kubernetes compliant to be easily used on the cloud helping to optimize cloud costs by supporting applications colocation providing turnkey services allowing you to create Minho applications in a minute Minho is composed by: minho-boot is the core of Minho. It contains the runtime launcher and the core services (service registry, lifecycle service, configuration service, ...). minho-* services provided additional functionnalities in the runtime. You can use these services to create your own services, it's also where you will find the services managing sepcific kind of applications, allowing colocation. minho-tooling optionally provide convenient tools to create your own runtime. It includes minho-maven-plugin for instance. In this blog post, we will take a quick tour on A...
Read more

Using Apache Karaf with Kubernetes

Image
In a previous blog post ( http://blog.nanthrax.net/?p=893 ), I introduced the “new” docker support in Karaf and the use of Karaf static distribution. This post follows the previous one by illustrating how to use Karaf docker image with a Kubernetes cluster. Preparing Karaf static docker image As in the previous blog post, we are preparing a Karaf static distribution based docker image. For this blog post, I’m using the example provided in Karaf: https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist . I’m just building the distribution as usual: karaf-docker-example-static-dist$ mvn clean install Preparing kubernetes testing cluster For this blog, I’m using a minikube installed locally. The installation is pretty simple: Download minikube from https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 Rename minikube-linux-amd64 as minikube Copy minikube in your path, for instance /us...
Read more