What's new in Apache Karaf 4.2.11 ?

Even if Apache Karaf 4.2.11 is a "minor" version on the Karaf 4.2.x series, it brings some interesting small stuff ;)

Karaf BoM

Like Apache Karaf 4.3.0, Karaf 4.2.11 now provides a Bill Of Material (BoM) siplifying the management of Karaf dependencies version.

All Karaf examples now use the BoM.

In your project, you can use the Karaf BoM like this:


The BoM provides all Karaf dependencies. It means you can use directly the Karaf dependencies like this:


You can see here, that you directly use the dependency maven coordinates without providing the version. The version is automatically provided by the Karaf BoM.

Features Service autoRefresh property

When you install (or update, or uninstall) a feature in Karaf, the Karaf Features Service embeds a resolver, dealing with all bundles capabilities and requirements.

It means that the Features Service is able to detect bundles requiring a refresh. If you don't use the Karaf Features Service, it means you have to deal with bundle refresh by your own (doing the refresh "by hand", for instance using bundle:refresh command), deciding if you really want to refresh or not.

The Features Service does a bundle refresh if:
  • a feature F installs a bundle B exporting package P. If bundle A has an optional import package P, bundle A will be refreshed in order to use package P
  • a feature F installs a bundle B exporting package P;version="2.0". If bundle A has an import package P;version="[1,3)" or P;version="1" (meaning version="[1,)") or P (meaning version="0.0.0" meaning version="[0.0.0,)"), bundle A will be refreshed in order to use updated version of package P
  • bundle B is refresh (for a reason mentionned above), bundle A imports a package provided by bundle B, so bundle A is refreshed (as bundle B is refreshed). NB: a "cascading" refresh can happen.
Several users complained about refreshes, because it can change the resolution or restart services. Even if a refresh happens with good reason, users want to "control" the refresh.

So, we introduce a new property in etc/org.apache.karaf.features.cfg configuration to disable automatic refresh:

# Define if the feature service automatically refresh bundles

true is the current behavior (default), meaning that the Karaf Features Service will detect and perform bundles refresh.

On the other hand, if you set autoRefresh=false, the Karaf Features Service will just install the feature resources (bundles, configuration files, configurations, inner features, ...), but no refresh will be triggered.

JMXMP improvement

Apache Karaf 4.2.10 introduced support of JMXMP connection. It means that you can connect to the Karaf MBean server via either JMXMP or RMI.

Apache Karaf 4.2.11 improves JMXMP support, with a better authentication layer using a plain SASL server. This plain SASL server is embedded and provided by Karaf (no need to add any external dependency).

We've also updated the official Karaf docker image to expose JMXMP 9999. As reminder, you can find the official Apache Karaf Docker images here: https://hub.docker.com/r/apache/karaf/tags?page=1&ordering=last_updated.

Related to JMX, for security reason, we also removed -Dcom.sun.management.jmxremote by default, to only use the Karaf JMX connection layer.

SSH client fix

Apache Karaf 4.2.10 upgraded to SSHD 2.5.1. Unforunately, SSHD 2.x changed the way of dealing with the streams, introducing a regression in Karaf SSHD server.

Concretely, for the users, it means that the SSH client doesn't exit cleanly, for instance once you execute a command. For instance, if you do:

$ ssh -p 8101 karaf@localhost 'info | grep "Karaf version"'
Password authentication
  Karaf version               4.2.10

and the ssh client is stuck there, it doesn't exit cleanly.

This has been fixed in Karaf 4.2.11:

$ ssh -p 8101 karaf@localhost 'info | grep "Karaf version"'
Password authentication
  Karaf version               4.2.11

Another issue has been reported on the Karaf client.

Apache Karaf 4.2.10 introduced the usage of environment variables in all configuration files. This is very interesting, especially when you are running Karaf on Kubernetes.

It's especially true for etc/org.apache.karaf.shell.cfg, where we can see the ORG_APACHE_KARAF_SSH_SSHPORT environment variable:

sshPort = ${env:ORG_APACHE_KARAF_SSH_SSHPORT:-8101}

If starting Karaf with export ORG_APACHE_KARAF_SSH_SSHPORT=8102 works fine for Karaf SSHD server, unfortunately, the Karaf SSH client (bin/client) was not able to parse etc/org.apache.karf.shell.cfg configuration file (Karaf SSH client tries to read this file to automatically use the right port number):

$ bin/start
$ bin/client
Logging in as karaf
Failed to get the session.

We see here that Karaf SSH client doesn't use the correct port number: it still uses 8101 instead of 8102 defined with ORG_APACHE_KARAF_SSH_SSHPORT environment variable.

It has been fixed in Karaf 4.2.11: now the Karaf SSH client is able to parse the config file correctly and use the environment variable:

$ bin/start
$ bin/client
Logging in as karaf
        __ __                  ____      
       / //_/____ __________ _/ __/      
      / ,<  / __ `/ ___/ __ `/ /_        
     / /| |/ /_/ / /  / /_/ / __/        
    /_/ |_|\__,_/_/   \__,_/_/         

  Apache Karaf (4.2.11)

Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit 'system:shutdown' to shutdown Karaf.
Hit '<ctrl-d>' or type 'logout' to disconnect shell from current session.


log:display and log:tail commands fix

To improve performance and reduce memory footprint, we improved the Karaf Log service using a CircularBuffer.

Unfortunately, the CircularBuffer implementation was not accurate, impacting log:tail command.

For instance, on Karaf 4.2.10, log:tail command looks "incomplete":

karaf@root()> log:tail
18:09:09.988 INFO [CM Configuration Updater (Update: pid=org.ops4j.pax.logging)] Sending Event Admin notification (configuration successful) to org/ops4j/pax/logging/Configuration

We can see a single line, whereas the buffer contains several.

The CircularBuffer has been fixed in Karaf 4.2.11, and log:tail command correctly render the log message (again ;)):

karaf@root()> log:tail
18:35:34.735 INFO [features-3-thread-1] Registering commands for bundle org.apache.karaf.log.core/4.2.11
18:35:34.738 INFO [features-3-thread-1]   org.apache.karaf.shell.commands/4.2.11
18:35:34.745 INFO [features-3-thread-1] Registering commands for bundle org.apache.karaf.shell.commands/4.2.11
18:35:34.746 INFO [features-3-thread-1]   org.apache.karaf.bundle.core/4.2.11
18:35:34.762 INFO [features-3-thread-1] Registering commands for bundle org.apache.karaf.bundle.core/4.2.11
18:35:34.763 INFO [features-3-thread-1]   org.apache.karaf.service.core/4.2.11

Dependencies update

As always on any Karaf release, Karaf 4.2.11 brings a bunch of dependency updates, some fixing dependency issue or addressing CVE.
  • Spring Security 5.4.2
  • Spring 5.3.4
  • Spring 5.1.20.RELEASE
  • Spring 5.0.20.RELEASE
  • Spring 5.2.13.RELEASE
  • Spring 4.3.30.RELEASE
  • eclipselink 2.7.8
  • Hibernate Validator 7.0.1.Final
  • Hibernate 5.4.29.Final
  • Align all Pax * dependencies
  • Jetty 9.4.39.v20210224
  • jline 3.19.0
  • Felix SCR 2.1.26
  • Felix Metatype 1.2.4
  • Felix EventAdmin 1.6.2
  • Felix ConfigAdmin 1.9.20
  • JNA 5.7.0
  • JUnit 4.13.2
  • ASM 9.1
  • Aries Blueprint 1.10.3
  • Aries Proxy 1.1.9
  • Felix HTTP 4.1.4
  • Felix Gogo 1.1.8
  • Felix Utils 1.11.6
  • Felix WebConsole 4.6.0
  • and much more !

Heading to Apache Karaf 4.3.1 and 5.0

Now Apache Karaf 4.2.11 has been released, the target is Karaf 4.3.1 fixing and improving Karaf 4.3.x series. In the meantime, we are working on the new main Karaf 5.0 version (complete Karaf refactoring).


Popular posts from this blog

Quarkus and "meta" extension

Getting started with Apache Karaf Minho

Apache Karaf Minho and OpenTelemetry