jbonofre's blog

We are working hard on Karaf 3.0. This major new version of Karaf will bring a lot of new features and enhancements. KAR in Karaf 2.2.4 As you may know, Karaf 2.2.x already provides “basic” KAR support. A KAR (KARaf archive) is a zip file which gathers a features XML and all bundles and configuration files dependencies. It means that a KAR is an atomic artifact which can be deployed without an Internet connection (as all is shipped in the KAR file itself). In Karaf 2.2.x, the KAR support was: a KAR deployer: you can copy a KAR file into the deploy folder, and KARAF will uncompress the KAR file, and install all features containing in the shipped features XML. a create-kar goal in the features-maven-plugin: this goal reads a features XML and creates a KAR file, ready to be deployed. So, all KAR logics were in the KAR deployer. It means that you are not able to deploy a KAR from a remote URL, etc. What’s coming in Karaf 3.0 The KAR service In Karaf 3.0, the KAR core bundle provides a org.

In my previous blog post, I introduced the Karaf Maven plugins. The Karaf Maven plugins are really helpful, starting from an existing POM. If you can write this POM by hand (it’s my favorite way ;)), we also provide several archetypes which create and pre-configure a Maven project for you. Karaf Archetypes The next Karaf release (2.2.5) provides a set of new archetypes: Assembly Archetype The karaf-assembly-archetype create a Maven project which create a custom Karaf distribution. It allows you to create your own Karaf distribution. The project downloads a Karaf standard distribution (in tar.gz and zip formats), unpack it, and create a new distribution. The easiest way to use it is to use the interactive mode: mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-assembly-archetype -DarchetypeVersion=2.2.5-SNAPSHOT Bundle Archetype If basically a bundle is a jar file with some special statement in the MANIFEST, the easiest way to create a bun

Apache Karaf is not only an OSGi container, it also provides a set of Maven plugins for tooling. In the next Apache Karaf 2.2.5 release, you will find two Maven plugins: cmdhelp-maven-plugin generates documentation (in DocBook or Scalate format) for Karaf commands features-maven-plugin provides a set of goals to manipulate Karaf features In this blog post, I will cover the features-maven-plugin as I think it’s the most interesting for your life with Karaf. Generate a features XML If I prefer to handle and create the features XML by hand, the features:generate-features-file goal could do it for you. It takes the dependencies of your project (described in the POM), and create the features XML. For instance, in the following example, a features XML file will be generated containing the commons-lang bundle: <xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-inst

Next version of Apache Karaf Cellar will include a DOSGi (Distributed OSGi) implementation. There are several existing DOSGi implementations: in Apache CXF (powered by the CXF stack), in Fuse Fabric, etc. The purpose of the Cellar one is to leverage the Cellar existing (Hazelcast instance, distributed map, etc), and to be very easy to use. Karaf Cellar DOSGi installation Cellar DOSGi is part of the main cellar feature. To install it: karaf@root> features:addurl mvn:org.apache.karaf.cellar/apache-karaf-cellar/3.0.0-SNAPSHOT/xml/features karaf@root> features:install cellar Distributed services You can note a new command available in Cellar: karaf@root> cluster:list-services It displays the list of services “cluster aware”. It means a service that could be used remotely from another node. Code sample To illustrate the Cellar DOSGi usage, we will use two bundles: the provider bundle is installed on node A and “expose” a distributed service the client bundle is installed on node B

Sad, too early ;). You know this feeling when something great is ended. I was at the ApacheCon NA11, Vancouver this week, and it was simply awesome. I gave two talks: Apache ServiceMix future ( http://people.apache.org/~jbonofre/smx_future.ppt ) Deployment with Apache Karaf and ACE ( http://people.apache.org/~jbonofre/deploy_karaf_ace.ppt ) On the other hand, I attended to the following session: Business and Open Source, open discussion with especially Bertrand (Delacretaz), Debbie (Moynihan), Ross (Turk) Apache, Branding and Trademark, with Shane (Curcuru) Archiva by Brett (Porter) Whirr by Tom (White) DOSGi and cloud by Guillaume (Nodet) I discussed with a lot of people: Of course Dan (Kulp), Hadrian (Zbarcea), Ross (Turk) Guillaume (Nodet), it was really great to work together, discussed about our roadmap for Karaf and ServiceMix, etc. Thanks a bunch Guillaume 😉 Christian (Muller) and Jon (Anstey), we talked about Camel. These guys are so cool 😉 Mohammad (Nour El-Din) about projec

Apache Karaf trunk (future 3.0 release) now fully supports OSGi 4.3 release by running Apache Felix framework 4.0.1 and Eclipse Equinox 3.7.1. If this update is just a support update, it gives us the opportunity to see what we can leverage from the OSGi r4 early draft. What’s in preparation in OSGi r4 ? I will not cover the whole OSGi 4 specification. I will just spot some features that will be “key” features in Karaf. New OBR specification (RFC-0112) Currently, there are a number of available solutions to downloading and installing bundles: current OBR stores the bundles and allows users to discover bundles P2 provisioning platform used in Eclipse Maven repositories as used in Karaf Nimble Repositories which are an extension of OBR to deal with active state dependencies The idea is to gather all these concepts into a new OBR specification. The new OBR will be able to: handle bundle fragments dependencies, provide management tooling can use a resolver strategy allowing to work with Fel

Apache Karaf 2.2.4 has been released this week end. You can take a look on the release notes . More than a bug fixes release, this version includes several new features and enhancements. Command aliases Previously, the osgi:* commands gathered different kind of usage: osgi:start, osgi:stop, etc are related to bundles, osgi:shutdown is related to container itself, and osgi:ls is OSGi service related. To be clearer for the users, new aliases have been introduced. NB: on Karaf trunk (future 3.0.0 release), the commands have been fully renamed (not aliased). system:* The system:* commands are related to the Karaf container itself:   system:shutdown is equivalent to osgi:shutdown and shutdown the Karaf container   system:start-level is equivalent to osgi:start-level and defines the default start-level to consider bundles as system bundles services:* The services:* commands are related to OSGi services: services:list is equivalent to ls and lists the OSGi services available bundles:* T

During the Karaf birthday concall, the Karaf team launched the idea of implementing an easy to use OBR (OSGi Bundle Repository) server, and extending it to provide a Karaf Features Repository (KFR). Welcome to Apache Karaf Cave 😉 Cave is an Apache Karaf sub-project. The core OBR is a service (RepositoryAdmin service) that can automatically install a bundle, with its deployment dependencies, from a repository. Cave is a work in progress in the Karaf Sandbox SVN. I think it’s time to provide an initial overview about what we can do with Cave. Cave already provides the following features: – Storage: Cave includes a storage backend to host the artifacts. The default storage is a filesystem. We designed the Cave backend to be plug and play. This means that you can implement your own storage backend. For instance, I hope to provide implementations to store the bundles into a database, a LDAP server, or use directly a Maven repository manager as Apache Archiva. – OBR Metadata Generation: Cav

Introduction Apache Camel has not be designed to be used for implementing batch tasks. For instance, if your Camel route has a consumer endpoint polling files in a directory, Camel will periodically and indefinitely monitor the folder and poll any new incoming files. It’s not a batch behavior: in batch mode, we want to run the file polling on demand, at a certain time, launched by a batch scheduler like ControlM, $Universe or Tivoli Worksheet Scheduler. However, there are several interesting points to use Camel for batch implementation. First, Camel provides a large set of components. A lot of batches read/write files, read from a JMS queues, write into JMS queues, etc. Usage of Camel components in a batch way is really valuable. Second, Camel uses a DSL to describe the process executed by the routes. Especially, it supports “human readable” DSL like Spring XML or Blueprint XML. It means that it’s easy to review what the batch is doing, eventually change an endpoint definition, etc. M

Apache CXF provides a really great layer to implement JAX-RS services. Especially, it fully supports OSGi, including Blueprint. It means that you can very easily create and deploy your REST services in a Apache Karaf container. In this example, we will see how to list all Karaf features via a REST service. This exemple is composed by three modules: – common is an OSGi bundle containing resources shared between the JAX-RS server and the clients. Basically, it contains the service interface and the objects used in the service. – service is an OSGi bundle providing the implementation of the service interface – client is a simple Main class that use CXF JAX-RS client Common bundle This bundle contains the interface describing the behavior of the REST service. We define it in the FeaturesRestService : package net.nanthrax.examples.jaxrs.common; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import java.util.Collection; /** * REST service to manipulate Karaf f