jbonofre's blog

When you use Apache Camel routes for your integration, when a failure occurs, a classic pattern is to retry the message. That’s especially true for the recoverable errors: for instance, if you have a network outage, you can replay the messages, hoping we will have a network recovery. In Apache Camel, this redelivery policy is configured in the error handler. The default and dead letter error handlers supports such policy. However, by default, the redelivered exchange is stored in memory, and new exchanges are not coming through since the first redelivered exchange with exception is not flagged as “handled”. This approach could be an issue as if you restart the container hosting the Camel route (like Apache Karaf), the exchange is lost. More other, in term of performance, we might want to still get the exchanges going through. There are several solutions to achieve this. In this blog, I will illustrate a possible implementation of a persistent redelivery policy with backoff support. Apa

When exposing a database as a REST or SOAP service, lot of users use: the integration perspective to create a service, but they don’t leverage Camel the mediation perspective to create a route containing a cTalendJob However, there’s an easy alternative. Using the mediation perspective, we can use directly a datasource exposed in the runtime (Karaf) as an OSGi service, and directly use Camel components. The advantages of this approach are: The same DataSource is shared by different routes and services. It means that we can use a PooledDataSource and optimize the connections to the database. We don’t use any Talend job, and directly leverage Camel native components. Route design in the studio We create a route in the mediation perspective of the studio. First, in the Spring tab, we add the DataSource OSGi service lookup. To do so, we add the spring-osgi namespace and use the osgi:reference element: <beans .... xmlns:osgi="http://www.springframework.org/schema/osgi" xs

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

MDC (Mapped Diagnostic Context) logging is an interesting feature to log contextual messages. It’s classic to want to log contextual messages in your application. For instance, we want to log the actions performed by an user (identified by an username or user id). As you have a lot of simultaneous users on your application, it’s easier to “follow” the log. MDC is supported by several logging frameworks, like log4j or slf4j, and so by Karaf (thanks to pax-logging) as well. The approach is pretty simple: You define the context using a key ID and a value for the key: MDC.put("userid", "user1"); You use the logger as usual, the log messages to this logger will be contextual to the context: logger.debug("my message"); After that, we can change the context by overriding the key: MDC.put("userid", "user2");logger.debug("another message"); Or you can remove the key, so to remove the context, and the log will be “global” (not local to

In any integration project, testing is vital for multiple reasons: to guarantee that the integration logic matches the expectations to quickly identify some regression issues to test some special cases, like the errors for instance to validate the succesful provisioning (deployment) on a runtime as close as possible to the target platform We distinguish two kinds of tests: the unit tests (utest) aim to test the behaviors of integration logic, and define the expectations that the logic has to match the integration tests (itest) aim to provision the integration logic artifact to a runtime, and check the behaviors on the actual platform Camel is THE framework to implement your integration logic (mediation). It provides the Camel Test Kit, based on JUnit to implement utest. In combinaison with Karaf and Pax Exam, we can cover both utest and itest. In this blog, we will: create an OSGi service create a Camel route using the Blueprint DSL, using the previously created OSGi service implement