Chapter 6. Camel Components

Table of Contents

ActiveMQ Component
CXF Component
Direct Component
File Component
FTP/SFTP/WebDAV Component
HTTP Component
JBI Component
JMS Component
JPA Component
Mail Component
MINA Component
Mock Component
Pojo Component
Quartz Component
Queue Component
RMI Component
Timer Component
XMPP Component

There now follows the documentation on each Camel component.

ActiveMQ Component

The ActiveMQ component allows messages to be sent to a JMS Queue or Topic ; or messages to be consumed from a JMS Queue or Topic using Apache ActiveMQ. This component is based on the JMS Component and uses Spring's JMS support for declarative transactions, using Spring's JmsTemplate for sending and a MessageListenerContainer for consuming.

URI format

activemq:[topic:]destinationName

So for example to send to queue FOO.BAR you would use

activemq:FOO.BAR

You can be completely specific if you wish via

activemq:queue:FOO.BAR

If you want to send to a topic called Stocks.Prices then you would use

activemq:topic:Stocks.Prices

Configuring the Connection Factory

The following ??? shows how to add an ActiveMQComponent to the CamelContext using the activeMQComponent() method while specifying the brokerURL used to connect to ActiveMQ

camelContext.addComponent("activemq", activeMQComponent("vm://localhost?broker.persistent=false"));

See Also

The ActiveMQ component allows messages to be sent to a JMS Queue or Topic ; or messages to be consumed from a JMS Queue or Topic using Apache ActiveMQ. This component is based on the JMS Component and uses Spring's JMS support for declarative transactions, using Spring's JmsTemplate for sending and a MessageListenerContainer for consuming.

So for example to send to queue FOO.BAR you would use

You can be completely specific if you wish via

If you want to send to a topic called Stocks.Prices then you would use

The following ??? shows how to add an ActiveMQComponent to the CamelContext using the activeMQComponent() method while specifying the brokerURL used to connect to ActiveMQ

The cxf: component provides integration with Apache CXF for connecting to JAX-WS services hosted in CXF.

The direct: component provides direct, synchronous invocation of any consumers when a producer sends a message exchange.This endpoint can be used connect existing routes or if a client in the same JVM as the Camel router wants to access the routes.

Where someName can be any string to uniquely identify the endpoint

The File component provides access to file systems; allowing files to be processed by any other Camel Components or messages from other components can be saved to disk.

Where fileName represents the underlying file name

By default the file is locked for the duration of the processing. Also when files are processed they are moved into the .camel directory; so that they appear to be deleted.

The following message headers can be used to affect the behaviour of the component

This component provides access to remote file systems over the FTP, SFTP and WebDAV protocols

Where fileName represents the underlying file name or directory

The http: component provides HTTP based endpoints for exposing HTTP resources or consuming external HTTP resources.

The jbi: component provides integration with a JBI Service Bus such as provided by Apache ServiceMix

The separator used will be:

For more details of valid JBI URIs see the ServiceMix URI Guide.

Using the jbi:service: or jbi:endpoint: URI forms will set the service QName on the JBI endpoint to the exact one you give. Otherwise the default Camel JBI Service QName will be used which is

If you have some Camel routes you want to deploy inside JBI as a Service Unit you can use the JBI Service Unit Archetype to create a new project.

If you have an existing maven project which you need to convert into a JBI Service Unit you may want to refer to the ServiceMix Maven JBI Plugins for further help. Basically you just need to make sure

Your pom.xml should look something like this to enable the jbi-service-unit packaging.

The JMS component allows messages to be sent to a JMS Queue or Topic; or messages to be consumed from a JMS Queue or Topic. The implementation of the JMS Component uses Spring's JMS support for declarative transactions, using Spring's JmsTemplate for sending and a MessageListenerContainer for consuming.

So for example to send to queue FOO.BAR you would use

You can be completely specific if you wish via

If you want to send to a topic called Stocks.Prices then you would use

If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. Note that the value of the clientId must be unique and can only be used by a single JMS connection instance in your entire network. You may prefer to use Virtual Topics instead to avoid this limitation. More background on durable messaging here.

You can configure lots of different properties on the JMS endpoint which map to properties on the JMSConfiguration POJO.

The jpa: component allows you to work with databases using JPA (EJB 3 Persistence) such as for working with OpenJPA, Hibernate, TopLink to work with relational databases.

Sending POJOs to the JPA endpoint inserts entities into the database. The body of the message is assumed to be an entity bean (i.e. a POJO with an @Entity annotation on it).

If the body does not contain an entity bean then use a Message Translator in front of the endpoint to perform the necessary conversion first.

Consuming messages removes (or updates) entities in the database. This allows you to use a database table as a logical queue, consumerse take messages from the queue and then delete/update them to logically remove them from the queue.

If you do not wish to delete the entity when it has been processed you can specify ?consumeDelete=false on the URI. This will result in the entity being processed each poll.

If you would rather perform some update on the entity to mark it as processed (such as to exclude it from a future query) then you can annotate a method with @Consumed which will be invoked on your entity bean when the entity bean is consumed.

For sending to the endpoint, the entityClassName is optional. If specified it is used to help use the Type Conversion to ensure the body is of the correct type.

For consuming the entityClassName is mandatory.

The mail: component provides access to Email via Spring's Mail support and the underlying JavaMail system

which supports either POP, IMAP or SMTP underlying protocols.

The mina: component is a transport for working with Apache MINA

Testing of distributed and asynchronous processing is notoriously difficult. The Mock Component provides a great tool for creating good integration test cases based on the Enterprise Integration Patterns using the various Components in Camel.

The Mock component provides a powerful declarative testing mechanism which is similar to jMock in that it allows declarative expectations to be created on any Camel Endpoint before a test begins. Then the test is ran which typically fires messages to one or more endpoints and finally the expectations can be asserted in a test case to ensure the system worked as expected.

This allows you to test various things like

Where someName can be any string to uniquely identify the endpoint

Here's a simple example of MockEndpoint in use. First the endpoint is resolved on the context. Then we set an expectation, then after the test has run we assert our expectations are met.

You typically always call the assertIsSatisfied() method to test that the expectations were met after running a test.

You can see from the javadoc of MockEndpoint the various helper methods you can use to set expectations. The mail methods available are as follows

Here's another example

In addition you can use the message(int messageIndex) method to add assertions about a specific message that is received.

For example to add expectations of the headers or body of the first message (using zero based indexing like java.util.List), you can use this code

There are some examples of the Mock endpoint in use in the camel-core processor tests.

The pojo: component is now just an alias for the Bean component.

The quartz: component provides a scheduled delivery of messages using the Quartz scheduler.Each endpoint represents a different timer (in Quartz terms, a Trigger and JobDetail).

You can configure the Trigger and JobDetail using the parameters

For example the following routing rule will fire 2 timer events to the endpoint mock:results

Quartz supports Cron-like expressions for specifying timers in a handy format. You can use these expressions in the URI; though to preserve valid URI encoding we allow / to be used instead of spaces and $ to be used instead of ?.

For example the following will fire a message at 12pm (noon) every day

which is equivalent to using the cron expression

The following table shows the URI character encodings we use to preserve valid URI syntax

The queue: component provides asynchronous SEDA behaviour so that messages are exchanged on a BlockingQueue and consumers are invoked in a seperate thread pool to the producer.

Note that queues are only visible within a single CamelContext. If you want to communicate across CamelContext instances such as to communicate across web applications, see the VM component.

Note also that this component has nothing to do with JMS, if you want a distributed SEA then try using either JMS or ActiveMQ or even MINA

Where someName can be any string to uniquely identify the endpoint within the current CamelContext

The rmi: component bind the PojoExchanges to the RMI protocol (JRMP).

Since this binding is just using RMI, normal RMI rules still apply in regards to what the methods can be used over it. This component only supports PojoExchanges that carry a method invocation that is part of an interface that extends the Remote interface. All parameters in the method should be either Serializable or Remote objects too.

For example:

To call out to an existing RMI service registered in an RMI registry, create a Route similar to:

To bind an existing camel processor or service in an RMI registry, create a Route like:

Notice that when binding an inbound RMI endpoint, the Remote interfaces exposed must be specified.

The timer: component provides timed events to Bean component. You can only consume events from this endpoint. It produces BeanExchanges that send a Runnable.run() method invocation.

Where options is a query string that can specify any of the following parameters:

To setup a route that generates an event every 500 seconds:

Note that the "bar" pojo registered should implement Runnable.

The xmpp: component implements an XMPP (Jabber) transport.

The component supports both room based and private person-person conversations