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

Quarkus and "meta" extension

Quarkus is a great Java framework with a large ecosystem thanks to the extensions . Basically, if using Maven, your pom.xml contains the list of the extensions you want to use, meaning something like this: ... <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-grpc</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-opentelemetry</artifactId> </dependency> ... It can quickly become large, and sometime you can have "conflict" between extensions (for example if you mix in the same dependencies set reactive and non reactive extensions). Quarkus "meta" extension To simplify the dependencies for the extensions you want to use (especially if it's basically the same extensions in all your services), you can create your own "meta" extension. This extension doesn't contain actual code, it "wraps" other exten
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

Apache Karaf Minho and OpenTelemetry

Image
Telemetry is an important part of a software stack, especially on distributed system (where services call each others). OpenTelemetry is a CNCF project coming from OpenTracing and OpenCensus. It provides API to easily instrument your code and tools to collect and export telemetry data (metrics, logs and traces). Before going into how to use OpenTelemetry with Minho, we have to understand some key concepts: Span is a single building block representing an operation or some unit of work that you want to capture. They are capable of standing on their own, referencing (or following) from other spans, storing metadata, tags, etc. Trace is a visualisation of the life of a request (or series of other operations) that is made up of one or more spans. This collection of spans work together to paint a picture of the overall request, allowing you to easily reconstruct what happened within each span, etc. SpanContext is a wrapper of key values pairs that associates a trace to one or mor
Read more