jbonofre's blog

Some months ago, I proposed Decanter on the Apache Karaf Dev mailing list . Today, Apache Karaf Decanter 1.0.0 first release is now on vote . It’s the good time to do a presentation 😉 Overview Apache Karaf Decanter is complete monitoring and alerting solution for Karaf and the applications running on it. It’s very flexible, providing ready to use features, and also very easy to extend. Decanter 1.0.0 release works with any Karaf version, and can also be used to monitor applications outside of Karaf. Decanter provides collectors, appenders, and SLA. Collectors Decanter Collectors are responsible of harvesting the monitoring data. Basically, a collector harvest the data, create an OSGi EventAdmin Event event send to decanter/collect/* topic. A Collector can be: Event Driven, meaning that it will automatically react to an internal event Polled, meaning that it’s periodically executed by the Decanter Scheduler You can install multiple Decanter Collectors in the same time. In the 1.0.0 re

Waiting for Karaf 3.0.0, we worked hard in the Karaf team to provide Apache Karaf 2.3.0. The Karaf 2.2.x branch is now only in maintenance mode: it means that no new features will be implemented in this branch, only major bug fixes. The new “stable” branch is now Karaf 2.3.x which is a perfect transition branch between Karaf 2.2.x (heavely used) and the future Karaf 3.x (which should arrive very soon). What’s new in this 2.3.0 release: * OSGi r4.3 : Karaf 2.2.x branch was powered by OSGi frameworks implementing OSGi r4.2 norm. Karaf 2.3.0 is now powered by the new OSGi r4.3 framework (Apache Felix 4.0.3 and Equinox 3.8.x), for both OSGi core and compendium. It provides new features like weaving, etc. * Aries Blueprint 1.0.x : Karaf 2.3.0 uses the new Aries Blueprint version at different level (core, JMX, etc). * Update to ASM 4.0 : in order to work with Aries proxies, we updated to new ASM bundle. We also provided configuration that allows you to enable/disable weaving. * OSGi Regions

Apache Karaf Cellar 2.2.4 has been released. This release is a major release, including a bunch of bug fixes and new features. Here’s the list of key things included in this release. Consistent behavior Cellar is composed by two parts: the distributed resources which is a datagrid maintained by each cluster nodes and containing the current cluster status (for instance of the bundles, features, etc) the cluster event which is broadcasted from a node to the others Cluster shell commands, cluster MBeans, synchronizers (called at startup) and listeners (called when a local event is fired, such as feature installed) update the distributed resource and broadcast cluster events. To broadcast cluster events, we use an event producer. The cluster event is consommed by a consumer which delegates the handling of the cluster event to a handler. We have a handler for feature, bundle, etc. Now, all Cellar “producers” do: check if the cluster event producer is ON check if the resource is allowed, che

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

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

Camel provides Karaf features descriptor since quite a long time now. But Camel 2.8.0 will include new Karaf features very useful and turning Karaf and ServiceMix as the main container to run Camel. Install Camel in Karaf Installing Camel in Karaf is very simple as a features descriptor is provided. It means that you can register the Camel features descriptor in your running Karaf instance: karaf@root> features:addurl mvn:org.apache.camel.karaf/apache-camel/2.8.0/xml/features Now, you have the Camel features available: karaf@root> features:list|grep -i camel [uninstalled] [2.8.0 ] camel repo-0 [uninstalled] [2.8.0 ] camel-core repo-0 [uninstalled] [2.8.0 ] camel-spring repo-0 [uninstalled] [2.8.0 ] camel-blueprint repo-0 Deploy Camel features To start using Camel in Karaf, you have to install at least the camel feature: root@karaf> features:install camel Depending o