Tag Archives: Camel

Polling a JSON REST API using a custom Apache Camel component


via PALO IT – Polling a JSON REST API using a custom Apache Camel component.

If you have been playing around with integration frameworks, you are probably aware of Apache Camel, as it is one of the two big open source players together with the Spring Integration framework. While benchmarking Talend ESB and Redhat Fuse ESB products, which both include Apache Camel in their stack, I had the opportunity to dive a bit more into the concepts of the framework and figured there was some interesting material for a blog post !

The purpose of this post is to provide some guidelines to build a custom Camel component for your enterprise integration needs. Our example will show how to poll an external JSON-based REST API – in this case, the Feedly API – to periodically retrieve and process information – in this case, to log retrieved RSS feed titles.

Speeding Up ActiveMQ Persistent Messaging Performance by 25x


via Speeding Up ActiveMQ Persistent Messaging Performance by 25x – Software Blog.

Apache ActiveMQ is a very popular open-source messaging broker brought to you by the same people who created (and work on) Apache Karaf, Apache Camel, Apache ServiceMix, and many others. It has a vibrant community, is very flexible, and can be deployed in highly performant and highly available scenarios.

At Red Hat (where I work), we support a product called JBoss A-MQ, which is a production hardened, enterprise supported, fully opensource, version of the upstream ActiveMQ project. Red Hat is fully committed to opensource and all of our products are opensource (non of this open-core bull$hit) Our customers, and those specifically who use JBoss A-MQ, are the top in their respective fields (retail/e-retail, government, shipping, health providers, finance, telco, etc,etc.) and deploy JBoss A-MQ in highly critical scenarios.

Since the JBoss A-MQ codebase comes from the upstream ActiveMQ community, and all of the bug fixes and enhancements we do on the Red Hat side get folded back into the community, I’d like to share with you an enhancement we recently contributed that sped up our use case at a prominent customer by 25x, and could potentially help your use case as well. The patches that have been committed are in the master branch and won’t be available until the 5.12 community release (although will be available in a patch to JBoss A-MQ 6.1 sooner than that, hopefully end of this week or early next week), though I encourage you to checkout a nightly SNAPSHOT of 5.12 to try it out sooner (nightly snapshots can be found here) .

Maven SLF4J integration example


via Maven SLF4J integration example.

In this example, we shall show you how to integrate Apache Maven with SLF4J. Apache Maven is a software project management and comprehension tool. It provides powerful features like superior dependency management including automatic updating and transitive dependencies.

It follows the principle of convention over configuration, due to which one can start with a minimal configuration and sensible defaults will be provided for all the missing configuration.

Maven uses central repositories where various artifacts like JAR files can be hosted. It comes with a mechanism that resolves all project dependencies from these central repositories. So effectively you are resolved from keeping and providing JAR files on your project’s classpath.

Maven only needs a file called ‘pom.xml’ where one can define dependencies as we will be seeing in the example below. Once you choose to build the project, these dependencies will be automatically fetched from central repository and put on your application’s classpath.

SLF4J is a simple facade over various logging frameworks. It gives abstraction and therefore makes it easier to change logging implementations later on in a software project.It is a very stable library and is actively used by various open source software like Apache Camel, ActiveMQ, Solr and EhCache etc. For this example we will be using Apache Maven 3.2.5 and SLF4J 1.7.5. The example is compilable on Java 5 and above.

Riding Camel on Java EE 7 – REST Services with Swagger Documentation


via Riding Camel on Java EE 7 – REST Services with Swagger Documentation ~ Enterprise Software Development with Java.

Camel comes with a bunch of features out of the box. One of them is the Swagger integration. Unfortunately, most of the already-there features heavily rely on Spring. But this should not stop us from using them in plain Java EE 7 applications, because it sometimes is just the more lightweight variant of doing things. But I don’t want to start a discussion about this again. Instead, I think that there is a technology choice for all situations and if you run across a project you just want to use Camel with Java EE 7 and you need REST services and want to document them with Swagger, this is the right post for you.

Apache Camel please explain me what these endpoint options mean


In the upcoming Apache Camel 2.15, we have made Camel smarter. It is now able to act as a teacher and explain to you how its configured and what those options mean. Read more>>

Apache Camel 2.14: Java 8, Spring 4, REST DSL and Metrics


Apache Camel 2.14: Java 8, Spring 4, REST DSL and Metrics

The Apache Camel team recently released version 2.14, their 66th release. Camel is an open-source integration framework that provides components based on the popular enterprise integration patterns. It allows an application to define route and mediation rules in many domain-specific languages (DSLs), for example with Java, XML, Groovy and Scala.

New features include a REST DSL and Swagger integration for easily documenting an API, as well as new support for Java 8 (Java 6 is no longer supported) and Spring 4 (users of Spring 3.x or earlier will need to use camel-test-spring3 for testing). A Java 8 specific DSL that allows for lambda expressions was deferred until the next release.

In a blog post entitled Easy REST endpoints with Apache Camel 2.14, Christian Posta, Principal Middleware Specialist/Architect at Red Hat wrote: