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: 


    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.apache.karaf</groupId>
                <artifactId>karaf-bom</artifactId>
                <version>4.2.11</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
The BoM provides all Karaf dependencies. It means you can use directly the Karaf dependencies like this: 

        <dependency>
            <groupId>org.osgi</groupId>
            <artifactId>osgi.core</artifactId>
        </dependency>
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
#
#autoRefresh=true
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
Password:
  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
Password:
  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): 

$ export ORG_APACHE_KARAF_SSH_SSHPORT=8102
$ 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: 


$ export ORG_APACHE_KARAF_SSH_SSHPORT=8102
$ 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.

karaf@root()>

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).

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