Showing posts from August, 2011

Apache Karaf Cave preview

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

Use Camel, CXF and Karaf to implement batches

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

JAX-RS services using CXF and Karaf

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; import; import; import java.util.Collection; /** * REST service to manipulate Karaf f

Use a "remote" EJB in Camel routes

Introduction You have an existing application, let say developed using J2EE, including EJB (Session). The application is running into a J2EE application server like JBoss, WebSphere or Weblogic. This application “exposes” EJBs to perform some business services. Now, you can to use these “remote” EJBs into Camel routes. Context We want to “expose” the EJB using WebService. As for all EJBs, we have two interfaces for our EJB: the local and remote interfaces. Let assume that we have: * ejb.MyEjbSession * ejb.MyEjbSessionHome We assume that the MyEjbSession EJB provides a businessMethod() method, with a String in argument, and returning a String. The first thing to do is to define an interface containing the WebService annotation. This interface will define the operations and will be used to generate the WSDL on the fly: package; @WebService(targetNamespace = "", name = "MyEjbService") public interface MyEjbService {  

Apache Karaf Cellar 2.2.2 release

What’s new Quite one month ago, we released Karaf Cellar 2.2.1, the first “official” release of the Karaf clustering sub-project. This new Karaf Cellar 2.2.2 release includes bug fixes, especially one bug was a blocker as it was not possible to install Cellar on a Karaf instance running on Equinox OSGi framework. But, it’s not just a bug fix release, we merge two features from the Cellar trunk. Bundle synchronization In Karaf Cellar 2.2.1, we were able to synchronize features (including features repositories) and configuration between Karaf Cellar instances. It means that you can install a feature on one node (cluster:features-install group feature), the feature will be install on each Karaf note. Karaf Cellar 2.2.2 includes the same behavior for pure OSGi bundle. You can install a bundle on one node, the bundle will be installed on each other nodes on the same cluster group. karaf@root> osgi:install mybundle mybundle will be installed on all nodes in the same cluster group. It’s a