What's new in Apache Karaf 4.3.1 ?
Apache Karaf 4.3.1 has just been released. It's now available on http://karaf.apache.org/download.html.
It contains the same features as Apache Karaf 4.2.11, you can find on https://nanthrax.blogspot.com/2021/03/whats-new-in-apache-karaf-4211.html.
Of course, Karaf 4.3.1 contains some specific fixes and improvements.
Updated system packages (for OSGi R7)
Since OSGi R7, thejava.* packages should be exported by the framework (aka system packages).
As Karaf 4.3.x is based on OSGi R7, it should do it.
Karaf uses configuration file to list the packages exported by itself. Regarding the packages provided by the JDK, Karaf use etc/jre.properties to export the packages depending of the JDK version (aka the execution environment).
Karaf 4.3.1 has been updated to cleanly export java.* packages, and it has been done by adding these packages in etc/jre.properties configuration file.
Features JSON format
Karaf Features is the main provisioning extension for Apache Karaf. Basically, your application is described as a set of Karaf features. Since the beginning of Karaf, the descriptors (aka features repositories) use XML format. For instance, a features repository can look like:
<<xml version="1.0" encoding="UTF-8"?>
<features name="my-features-repo" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
<repository>mvn:groupId/other-repo/1.0/xml/features</repository>
<feature name="my-feature" version="1.0">
<feature>dependent-feature</feature>
<bundle>mvn:groupId/my-bundle/1.0</feature>
<configfile finalName="/etc/my-config-file">http://host/path/to/config/file</configfile>
<config name="my-other">foo=bar</config>
<bundle>file:/path/to/other/bundle.jar</bundle>
</feature>
</features>
You can fully describe your application and system with several features, each feature can contain reference to other features, bundles, configuration files, and "raw" configuration.
With Karaf 4.3.1, you can still use XML format for features repository, but now, you can also use JSON format.
Karaf Features service checks the format on the features repository URL and automatically detects if it's XML features repository or a JSON features repository.
It means that you can describe your features in a JSON repository, like this:
{
"name": "my-features-repo",
"repository": [ "mvn:groupId/other-repo/1.0/xml/features" ],
"feature": [
{
"name": "my-feature",
"version": "1.0",
"feature": [ "dependent-feature" ],
"bundle": [ { "location": "mvn:groupId/my-bundle/1.0" }, { "location": "file:/path/to/other/bundle.jar" } ],
"configfile": [ { "finalname": "/etc/my-config-file", "location": "http://host/path/to/config/file" } ],
"config": [ { "name": "my-other", "value": "foo=bar" } ]
}
]
}
You can mix XML and JSON formats in the same Karaf runtime.
Fix on JSON configuration files
Karaf 4.3.x introduced support of JSON format for configuration files (located inetc directory).
We identified a minor issue with this new feature: by default, when a configuration is created, Karaf uses JSON format by default (so the json file extension) instead of properties file (so the cfg file extension) as it was.
So, we fix that: Karaf uses cfg configuration files by default. If you want to use the json format, you have either:
- create the json file by hand in the
etcfolder - add a property
felix.fileinstall.filenamein the configuration. Karaf will "find" the json extension.
Jetty alias feature for backward compatibility
Some users and third party projects (I'm thinking about Apache Camel or Apache CXF) use Karaf features (standard) in their own features. Since Karaf 4.3.0, we have a better HTTP service provider support where the user can decide to use easily (low coupled) jetty, tomcat, undertow. It's up to the user to decide the HTTP service provide he wants to use. To avoid confusion, we renamed (cleaner ;)) the HTTP related features. Especiallyjetty feature became pax-web-jetty as Jetty container support is provided by Pax Web in Karaf.
Unfortunately, users directly depends to jetty feature. It's the case especially for Apache Camel.
For backward compatibility, and allow users to move "smoothly" on Karaf 4.x, Karaf 4.3.1 introduces jetty "alias" feature (actually referencing pax-web-jetty).
Resolver parallelism on Kubernetes
The Karaf features resolver (computing the features graph, and defining if a feature is complete or not) uses Felix Resolver. To optimize the resolution speed, the resolver can use multiple threads. To optimize this, we introduceresolverParallelism option on the resolver (and so on the karaf-maven-plugin as well). By default, this option is set with max number of processors detected on the machine, or 1:
int resolverParallelism = Math.max(1, Runtime.getRuntime().availableProcessors());
Unfortunately, when we have a single processor on the machine, some features can't be resolved successfully as another thread has to be used for inner features.
That's especially true on Kubernetes where a pod has a single assigned CPU.
So, we change that to a default parallelism of 2 to allow inner features resolution. Anyway, the workaround with Karaf 4.3.0 is to set the parallelism to 2 "by hand".
Comments
Post a Comment