Archive for: ‘November 2011’

Apache Karaf Cellar and DOSGi

November 29, 2011 Posted by jbonofre

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 and will use the provider service

Provider bundle

The provider bundle expose an OSGi service, flagged as a distributed service.

The service is very simple, it’s just an echo service.

Here’s the interface describing the service:

package org.apache.karaf.cellar.sample;

public interface EchoService {

  String process(String message);


and the corresponding implementation:

package org.apache.karaf.cellar.sample;

public class EchoServiceImpl implements EchoService {

&nbps; public String process(String message) {
    return "Processed by distributed service: " + message;


Up to now, nothing special, nothing related to DOSGi or Cellar.

To expose the service in Karaf, we create a blueprint descriptor:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="">

  <bean id="echoService" class="org.apache.karaf.cellar.sample.EchoServiceImpl"/>

  <service ref="echoService" interface="org.apache.karaf.cellar.sample.EchoService">
      <entry key="service.exported.interfaces" value="*"/>


We can note that the only “special” part is that we added the service.exported.interfaces property to the echoService.

It’s just a flag to define the interface/service to define as distributed (it means accessible from remote node).

We didn’t change the code of the service itself, just added this property. It means that it’s really easy to turn an existing service as a distributed service.

Client bundle

The client bundle will get a reference to the echoService. In fact, the reference will be a kind of proxy to the service implementation located remotely, on another node.

The client is really simple, it indefinitely iterates to use the clusterService:

package org.apache.karaf.cellar.sample.client;

public class ServiceClient {

  private EchoService echoService;

  public void setEchoService(EchoService echoService) {
    this.echoService = echoService;

  public EchoService getEchoService() {
    return this.echoService;

  public void process() throws Exception {
    int count = 0;
    while (true) {
      System.out.println(echoService.process("Call " + count));


We inject the echoService using Blueprint:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="">

  <reference id="echoService" interface="org.apache.karaf.cellar.sample.EchoService"/>

  <bean id="serviceClient" class="org.apache.karaf.cellar.sample.client.ServiceClient" init-method="process">
&nbps;   <property name="echoService" ref="echoService"/>


It’s done. The serviceClient will use the echoService. If a “local” echoService exists, the OSGi framework will bind the reference to this service, else Cellar will look for a distributed service (on all node) exporting the EchoService interface and bind a proxy to the distributed service.

ApacheCon NA11 2011: so great

November 12, 2011 Posted by jbonofre

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:

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 projects in the incubator, proposals, etc
  • Brett (Porter) and Carlos (Sanchez) about Archiva
  • Marcel (Offermans), Alex, Bram, about ACE and OSGi
  • lot of others (Bertrand, Shane, etc, etc) that I would like to thank too

Once again, thank you all.

See you in November 2012 for the ApacheCon Europe, Germany 😉

Apache Karaf moved to OSGi r4.3

November 3, 2011 Posted by jbonofre

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 Felix OBR, Sigil or Nimble
  • a normalized and new OBR XML schema, supporting bundle execution environment, etc.

Karaf Cave will be the perfect place to leverage new OBR specification implementation. It will allow Karaf to deploy bundles provided by P2, OBR, Nimble, etc.

Karaf Cave will also extend the OBR specification in order to directly handle Karaf features.

ACE will also use this new OBR specification for the ACE repository implementation.

Subsystems (RFC-0152)

Most of container defines a concept to gather bundles together and provide complete applications.

Depending of the container, we have different wording:

  • in Karaf, we name it features
  • in Spring DM, the name is applications
  • in Aries, it’s applications too
  • in Eclipse, it’s features or installable units

If the core concept is the same, the implementations are very different.

The Subsystems specification aim to use an unique way to define the concept of applications.

Subsystems leverages others OSGi technologies:

  • OBR, we already discussed about that in the first section. It’s the repository used to store all bundles required to be deploy to form an application.
  • framework hooks (RFC-0138) to isolate or group subsystems within a single OSGi framework.
  • deployment admin defines a file format to ship and deploy applications.
  • application admin provides the concept of an application in OSGi.

Subsystems could become a key feature in Karaf 3.0, as it could handle Karaf features and KAR.

We implemented in features concepts defined in this specification. For instance, in a Karaf features, we can use an OBR resolver.

More over, subsystems provides new features missing in the current Karaf features, especially a complete lifecycle, better subsystems dependencies.

Regarding the new OBR and subsystems specifications, we can have a consistent way to deploy applications and bundles.

OSGi for Enterprise (RFC-0164 and RFC-0146)

RFC-0146 covers Java EE JCA for OSGi. It will provides support for resource adapters, packaged as a RAR. The resources can be integrate with OSGi services.

On the other hand, RFC-0164 deals with Blueprint Declarative Transaction. It means that we can define the transaction on a bean methods by declaration in the blueprint descriptor:

<bean ...>
<tx:transaction method="count*" value="Required"/>
<tx:transaction method="count*Row" value="RequiresNew"/>

These two specifications are a step forward to a Karaf EE distribution, by including such features and providing others.

OSGi JMX (RFC-0169)

Lot of comments and bugs have been raised regarding the OSGi-JMX specification.

This specification aim to implement most of suggestions and fix bugs.