Karaf 4.0 is about to be released !


Almost 3 years since I haven't blogged, so I'm using the fact that the Karaf 4.0 release in under vote to start again.

Karaf 4.0 brings a lot of new features, but one of the most important one is the new features service.  It is originally a port of the Fuse/Fabric agent resolver to Karaf 4, but has since been extended a lot (and has actually been integrated back into Fuse 6.2).

This new features services is used to install well known features, but even if it reuses the same features xml definition, it's not limited to those anymore and works in a very different way.  The main difference is that the original features service (in Karaf 2.x and 3.x) is quite blind when it comes to installing features.  When a user asks for a feature installation, the process was quite simplistic: the service mainly goes through the list of bundles listed in the feature and install them.  The introduction of the resolver flag brought some intelligence to the process, as the old and deprecated OBR library was used to compute which bundles were actually needed.  The goal was to be smarter and not install bundles if they were not needed.
However, OBR was quite limited, and the output of OBR could theorically not be supported by the OSGi framework, or at least, not give the expected results.

The new resolver reuses the OSGi resolver, the exact same one that is used by the OSGi framework.  It also reuses the same metadata extracted from the bundle headers.  The new OSGi resolver is really generic and supports any kind of requirements and capabilities, even though it contains specific rules for known kind of constraints.
The new features service uses this resolver, by translating feature definitions into resoures with their requirements and capabilities, including bundles, but also conditionals, feature dependencies, etc...  Once the modelling is done, the service asks the resolver for an output, and brings the framework into the desired state by installing, uninstalling, updating bundles as needed.

This is major change, even though the end-user does not always see it immediately.  The features service maintains a set of requirements (usually requirement on features), and the resolution will always satisfy those requirements.  This means that the installation of a feature can not fail previously installed features, nor can it installs a feature that can't be resolved.

There are lots of new stuff coming with this new features service, and I'll try to cover some of them over the next weeks.

Comments

Post a Comment

Popular posts from this blog

Apache Karaf

ApacheCon was really interesting this year! Recently, a lot of people have expressed a real interest in ServiceMix Kernel , our generic OSGi distribution for server side applications. We've been discussing moving this subproject into Apache Felix for several reasons: raise the visibility and awareness on ServiceMix Kernel attract a broader community Several Apache projects are planning to use ServiceMix Kernel as their container: this includes Apache James , Apache Directory and Apache ActiveMQ . The Apache Sling community is also willing to contribute to this effort along with some other groups like the OPS4J project. During this discussion, a name as been proposed by Jamie Goodyear: Apache Karaf . A carafe is a small container used for serving wine and other drinks (http://en.wikipedia.org/wiki/Carafe). In similarity to the name the Kernel allows applications to be more easily handled, and improves their characteristics (much like a bottle of wine left to breath in a dec...
Read more

Camel Endpoint DSL

Image
Camel Endpoint DSL One of the new features of Camel 3.0  is an Endpoint DSL.  This new API aims to provide a type safe replacement for the URLs that are used in Camel to designate the consumer or producer endpoints.  These URLs provide 3 things: the scheme of the URL identifies the component to use, a unique name or id for the endpoint, and a set of parameters to customize the endpoint behavior. Here is an example of an FTP consumer endpoint definition: from( "ftp://foo@myserver?password=secret& recursive=true& ftpClient.dataTimeout=30000& ftpClientConfig.serverLanguageCode=fr" ) .to( "bean:doSomething" ); There are several drawbacks with such constructs : no type safety, bad readability and no simple completion. So we now use the meta model, which is currently extracted from the source using an annotation processor and written in various JSON files, to generate a fluent DSL for each endpoint.  The same...
Read more

ActiveMQ Pooling

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ . I discovered two things: * ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side). * ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX). The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are no...
Read more