One of the first purpose of Apache Karaf Cellar is to synchronize the state of each Karaf instances in the Cellar cluster.

It means that any change performed on one node (install a feature, start a bundle, add a config, etc) generates a “cluster event” which is broadcasted by Cellar to all others nodes. The target node handles the “cluster event” and performed the corresponding action (install a feature, start a bundle, add a config, etc).

By default, the nodes have the same role. It means that you can perform actions on any node.

But, you may prefer to have one node dedicated to the management. It’s what we name “central management”.

Central management

With central management, one node is identified by the manager. It means that cluster actions will be performed only on this node. The manager is the only one which is able to produce cluster event. The managed nodes are only able to receive and handle events, not to produce.

With this approach, you can give access (for instance grant ssh or JMX access) to the manager node to an operator and manage the cluster (and all cluster groups) from this manager node.

We will see now how to implement central management.

We assume that we have three nodes:

• manager
• node1
• node2

First, we install Cellar on the three nodes:


karaf@manager> features:addurl mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.4-SNAPSHOT/xml/features
karaf@manager> features:install cellar



karaf@node1> features:addurl mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.4-SNAPSHOT/xml/features
karaf@node1> features:install cellar



karaf@node2> features:addurl mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.3/xml/features
karaf@node2> features:install cellar


It’s a default installation, nothing special here.

Now, we disable the event producing on node1 and node2.

To do that, from the manager:


karaf@manager> cluster:producer-stop node1:5702
Node Status
node1:5702 false
karaf@manager> cluster:producer-stop node2:5703
Node Status
node2:5703 false


We can check that the producer are really stopped:


karaf@manager> cluster:producer-status node1:5702
Node Status
node1:5702 false
karaf@manager> cluster:producer-status node2:5703
Node Status
node2:5703 false


Whereas the manager is always able to produce event:


karaf@manager> cluster:producer-status
Node Status
manager:5701 true


Now, for instance, we can install eventadmin feature from the manager:


karaf@manager> cluster:features-install default eventadmin


We can see that this feature has been installed on node1:


karaf@node1> features:list|grep -i eventadmin
[installed ] [2.2.5 ] eventadmin karaf-2.2.5


and node2:


karaf@node2> features:list|grep -i eventadmin
[installed ] [2.2.5 ] eventadmin karaf-2.2.5


Now, we uninstall this feature from the manager:


karaf@manager> cluster:features-uninstall default eventadmin


We can see that the feature has been uninstall from node1:


karaf@node1> features:list|grep -i eventadmin
[uninstalled] [2.2.5 ] eventadmin karaf-2.2.5


And now, we try to install the eventadmin feature on the cluster from the node1:


karaf@node1> cluster:features-install default eventadmin


The event is not generated and the others nodes are not updated.

However, two kind of events are always produced (even if the producer is stopped):

• the events with the “force” flag. When you create an event (programmatically), you can use setForce(true) to force the event producing.
• the “admin” events, like the events produced to stop/start a producer, consumer, handler in the cluster.

NB: the event produce handling has been largely improved for Cellar 2.2.4.

Coming in next Cellar release

Currently, the cellar feature install the cellar core bundles, but also the cellar shell commands, and the MBeans.

If it makes sense for the manager, the managed nodes should not “display” the cluster:* commands as they are managed by the manager.

I will make a little refactoring of the Cellar features to split in two parts:

• the cellar-core feature will install hazelcast, and Cellar core bundles
• the cellar-manager feature will install the cluster:* shell commands and the MBeans

Around one week ago, we released Karaf Cellar 2.2.3.

In addition of the first Distributed OSGi support (DOSGi, I already wrote blog), an interesting feature of Cellar 2.2.3 is to give access the whole Hazelcast configuration.

The etc/hazelcast.xml is the core configuration of the Hazelcast instance, started by the Cellar feature. Cellar registers the Hazelcast instance as an OSGi service.

It means that we can use the Hazelcast instance just using a reference to the corresponding OSGi service. We are going to use the Hazelcast OSGi service in a Camel route defined using blueprint DSL (it works using Spring DSL as well).

Apache Camel 2.9.0 and the Hazelcast component

Camel 2.9.0 provides a new component: camel-hazelcast.

This component allows to send (as a producer/to) or receive (as a consumer/from) a Camel exchange through a Hazelcast distributed queue.

The first route timerToQueue fires a message every 5 seconds, and send to a Hazelcast distributed queue.

This distributed queue will be in the Hazelcast instance registered as an OSGi service by Cellar.


<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:camel="http://camel.apache.org/schema/blueprint"
  xsi:schemaLocation="
    http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
    http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">

</blueprint>


On the other hand, the queueToFile route get the exchange from the distributed queue and send to a file.


<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:camel="http://camel.apache.org/schema/blueprint"
  xsi:schemaLocation="
    http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
    http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">

</blueprint>


The two routes are on different Cellar nodes, the communication uses a queue distributed on all Hazelcast instances (handle by Karaf Cellar).

Conclusion

Lot of Camel users mostly use a JMS queue to “connect” two remote Camel routes. It requires a MQ broker, with a network connector if you want failover/cluster, etc. So it’s required special configuration, etc.

Now, we have an alternative using Cellar, which is just a feature to install, without point of failure (a Hazelcast instance is present on each Cellar node).

At boot, my system hangs up just after the /scripts/init-bottom phase.

I tried with kernel 3.0.0-14, the behavior is the same. The latest working kernel was 3.0.0-13.

After digging, it’s when the init-bottom performs vgchange -a y.

The problem is that the script is waiting for the udev device, and starting from kernel 3.0.0-14, it doesn’t work and we raise the timeout.
So it means that the startup is not totally stuck, it just takes long long long time

The workaround is to disable the udev support during LVM2 vgchange.

To do that, edit the /lib/udev/rules.d/85-lvm2.rules and add the --noudevsync option to vgchange:


SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange --noudevsync -a y'"


We have to update the initramfs:


update-initramfs -u -k all


Karaf 2011 is a good millésime with the following activity:

• New sub-projects: 3 (Cellar, Cave, WebConsole)
• Number of commits: 1,851
• Number of releases: 11
• Number of messages on the forums/mailing lists: 3119
• Number of direct downloads: 44,829
• Number of tickets open/resolved: 782/577
• Karaf active team: 12

A good millésime for sure.

Now, it’s time to focus on the 2012 vendange

Thanks for the Karaf users and the wonderful Karaf team

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.apache.karaf.kar.KarService OSGi service.

This service allows you to list the installed KAR files, deploy a KAR file from an URL, uninstall a KAR file.

Now the KAR service use a data/kar directory to store the KAR file and uncompress the KAR directly in the system repository (the local-repo directory is no more needed and created).

The KAR shell commands

Now, you have a complete control on the KAR files (including remotely using a SSH connection).

You can list, install, and uninstall KAR files using the kar:* commands:

• kar:list displays the installed KAR files
• kar:install installs a KAR file from a given URL. The URL could be a “classic” file: or http:, but, as for all stuff in Karaf, mvn: (for instance mvn:net.nanthrax/test/1.0-SNAPSHOT/kar)
• kar:uninstall uninstalls a KAR file (identified by the name as displayed by kar:list). This command doesn’t alter the system repository by default, but you have an option -c (–cleanup) to cleanup the system repository.

The KAR MBean

You can also manipulate KAR files using JMX via a new MBean: org.apache.karaf:type=kar,name=root.

This MBean provides quite the same actions that you can do using the commands:

• getKars()
• install(url)
• uninstall(name)
• uninstall(name, clean)

In progress

It’s still a work in progress. I will add a bunch of unit tests and new features around the KAR files.

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 bundle is to use the Felix maven-bundle-plugin.

Karaf provides an archetype which prepare a Maven project and provide a bundle Activator (a special callback class when the bundle start/stop).

To generate this project, simply type:


mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-bundle-archetype -DarchetypeVersion=2.2.5-SNAPSHOT


NB: I think that this archetype should be in Felix (as the same level as maven-bundle-plugin), I will propose a donation to the Felix community.

Blueprint Archetype

Blueprint is IoC approach applied to OSGi (it comes from Spring DM in fact). It allows you to avoid to write bundle Activator, ServiceTracker, etc.

Karaf provides a karaf-blueprint-archetype which prepare a Maven project including the maven-bundle-plugin, and a blueprint descriptor with a sample of OSGi service definition:


mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-blueprint-archetype -DarchetypeVersion=2.2.5-SNAPSHOT


NB: I think that this archetype should be in Aries (as it’s the blueprint implementation used in Karaf), I will propose a donation to the Aries community.

Feature Archetype

In Karaf, a feature is an application descriptor, defining all bundles, configurations/configuration files, others features. This features descriptor could be generated by hand (it’s my favorite way, and I guess the recommended one), we also provide a archetype which prepare a project to generate features file regarding the POM dependencies:


mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-feature-archetype -DarchetypeVersion=2.2.5-SNAPSHOT


Kar Archetype

We saw in my previous post a new goal of the features-maven-plugin to create a kar file starting from a features XML. A KAR file is a zip file containing the features XML and all its dependencies.

We also provide an archetype to prepare a Maven project containing a features XML and generate a KAR file:


mvn archetype:generate -DarchetypeGroupId=org.apache.karaf.archetypes -DarchetypeArtifactId=karaf-kar-archetype -DarchetypeVersion=2.2.5-SNAPSHOT


Pax-Web Archetypes

We also add several archetypes in Pax Web to deal with the web bundle. Charles talk about wab-gwt archetype in his last blog entry (http://cmoulliard.blogspot.com/2011/12/run-google-web-toolkit-2-project-on.html), but I added also two others.

Web Bundle Archetype

The Web Bundle Archetype create a “special” bundle containing web resources and statements. It creates a Maven project with webapp resources and WebApp Context in the POM:


mvn archetype:generate -DarchetypeGroupId=org.ops4j.pax.web.archetypes -DarchetypeArtifactId=wab-archetype -DarchetypeVersion=1.1.2-SNAPSHOT


War Archetype

We also provide an archetype to create a Maven project which generate a standard war (that you can deploy “outside” of OSGi) but including OSGi statements in the MANIFEST (which allows you to use OSGi values):


mvn archetype:generate -DarchetypeGroupId=org.ops4j.pax.web.archetypes -DarchetypeArtifactId=war-archetype -DarchetypeVersion=1.1.2-SNAPSHOT


Camel Archetypes

Camel also provides a set of very useful archetypes, especially:

• camel-archetype-blueprint to generate a Maven project with a blueprint XML in which you can define your routes
• camel-archetype-component providing a template to create your own Camel component
• camel-archetype-dataformat providing a template to create your own Camel data format
• camel-archetype-java providing a template with a class in which you can define your routes
• camel-archetype-spring to generate a Maven project with a Spring XML in which you can define your routes

For instance, to create a Camel blueprint Maven project, simply type:


mvn archetype:generate -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-blueprint -DarchetypeVersion=2.9-SNAPSHOT


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-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.karaf.tooling</groupId>
        <artifactId>features-maven-plugin</artifactId>
        <version>2.2.5-SNAPSHOT</version>
        <executions>
          <execution>
            <id>generate-features-filelt;/id>
            <goals>
              <goal>generate-features-file</goal>
            </goals>
            <configuration>
              <karafVersion>2.2.4</karafVersion>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>


You can find the features XML in the target directory.

Copy features resources in a local directory

The features:add-features-to-repo goal reads a set of features and copy features resources into a target folder. Especially, it allows you to prepare a custom distribution, allowing this distribution to avoid Internet connection to resolve features resources.

The following example will read a features XML and populate the target/system directory with the feature A, B, and C resources (bundles and configuration files):


<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-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.karaf.tooling</groupId>
        <artifactId>features-maven-plugin</artifactId>
        <version>2.2.5-SNAPSHOT</version>
        <executions>
          <execution>
            <id>add-features-to-repo</id>
            <goals>
              <goal>features-add-to-repo</goal>
            </goals>
            <configuration>
              <descriptors>
                <descriptor>file:${project.basedir}/src/main/resources/features.xml</descriptor>
              </descriptors>
              <features>
                <feature>A</feature>
                <feature>B/2.0-SNAPSHOT</feature>
              </features>
              <repository>target/system</repository>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>


NB: with Karaf 2.2.5, you can define a feature with just its name, or with name/version. It allows to target explicitly with which feature populate the target repository directory.

Create a KAR file

A KAR file (Karaf ARchive) is a zip file which package a features XML with all dependencies (bundles and configuration files).

It allows you to deploy (just by copying the kar file in the Karaf deploy folder) an atomic archive shipping all required resources (so no Internet connection is required).

The features:create-kar goal create a kar file starting from a given features XML.

The following example create a kar file (in the target folder) starting from a src/main/resources/features.xml:


<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-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.karaf.tooling</groupId>
        <artifactId>features-maven-plugin</artifactId>
        <version>2.2.5-SNAPSHOT</version>
        <executions>
          <execution>
            <id>create-kar</id>
            <goals>
              <goal>create-kar</goal>
            </goals>
            <configuration>
              <featuresFile>${project.basedir}/src/main/resources/features.xml</featuresFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>


Karaf 3.0 changes

In Karaf 3.0.0, you will find only one Maven plugin: karaf-maven-plugin, gathering the two “old” one.

The KAR support is also extended and give more place to KAR archives (used to construct distributions now).

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;

}


and the corresponding implementation:


package org.apache.karaf.cellar.sample;

}


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="http://www.osgi.org/xmlns/blueprint/v1.0.0">

</blueprint>


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;

}


We inject the echoService using Blueprint:


&lt?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">

</blueprint>


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.

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

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"/>
</bean>


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.