There now follows the documentation on each Camel 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.
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
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"));
The cxf: component provides integration with Apache CXF for connecting to JAX-WS services hosted in CXF.
cxf:address
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.
direct:someName
Where someName can be any string to uniquely identify the endpoint
Name | Default Value | Description |
allowMultipleConsumers | true | If set to false, then when a second consumer is started on the endpoint, a IllegalStateException is thrown |
The *??? component provides access to file systems.
file:fileName
Where fileName represents the underlying file name
Name | Default Value | Description |
initialDelay | 1000 | milliseconds before polling the file/directory starts |
delay | 500 | milliseconds before the next poll of the file/directory |
useFixedDelay | false | if true, poll once after the initial delay |
recursive | true | if a directory, will look for changes in files in all the sub directories |
attemptFileLock | false | if true, will only fire an exchange for a file it can lock |
regexPattern | null | will only fire a an exchange for a file that matches the regex pattern |
This component provides access to remote file systems over the FTP, SFTP and WebDAV protocols
ftp://host[:port]/fileName[?options] sftp://host[:port]/fileName[?options] webdav://host[:port]/fileName[?options]
Where fileName represents the underlying file name or directory
Name | Default Value | Description |
directory | false | indicates whether or not the given file name should be interpreted by default as a directory or file (as it sometimes hard to be sure with some FTP servers) |
password | null | specifies the password to use to login to the remote file system |
The http: component provides HTTP based endpoints for exposing HTTP resources or consuming external HTTP resources.
http:hostname[:port][/resourceUri]
The jbi: component provides integration with a JBI Service Bus such as provided by Apache ServiceMix
jbi:service:serviceQName jbi:interface:interfaceQName jbi:endpoint:endpointName
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.
jms:[topic:]destinationName?properties
So for example to send to queue FOO.BAR you would use
jms:FOO.BAR
You can be completely specific if you wish via
jms:queue:FOO.BAR
If you want to send to a topic called Stocks.Prices then you would use
jms:topic:Stocks.Prices
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.
If you are using ActiveMQ Note that the JMS component reuses Spring 2's JmsTemplate for sending messages. This is not ideal for use in a non-J2EE container and typically requires some caching JMS provider to avoid performance being lousy. So if you intent to use Apache ActiveMQ as your Message Broker - which is a good choice as ActiveMQ rocks
|
You can configure lots of different properties on the JMS endpoint which map to properties on the JMSConfiguration POJO.
Property | Default Value | Description |
acceptMessagesWhileStopping | false | Should the consumer accept messages while it is stopping |
acknowledgementModeName | "AUTO_ACKNOWLEDGE" | The JMS acknowledgement name which is one of: TRANSACTED, CLIENT_ACKNOWLEDGE, AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE |
autoStartup | true | Should the consumer container auto-startup |
cacheLevelName | "CACHE_CONSUMER" | Sets the cache level name for the underlying JMS resources |
clientId | null | Sets the JMS client ID to use. Note that this value if specified must be unique and can only be used by a single JMS connection instance. Its typically only required for durable topic subscriptions. You may prefer to use Virtual Topics instead |
concurrentConsumers | 1 | Specifies the default number of concurrent consumers |
connectionFactory | null | The default JMS connection factory to use for the listenerConnectionFactory and templateConnectionFactory if neither are specified |
deliveryPersistent | true | Is persistent delivery used by default? |
durableSubscriptionName | null | The durable subscriber name for specifying durable topic subscriptions |
exceptionListener | null | The JMS Exception Listener used to be notified of any underlying JMS exceptions |
explicitQosEnabled | false | Set if the deliveryMode, priority or timeToLive should be used when sending messages |
exposeListenerSession | true | Set if the listener session should be exposed when consuming messages |
idleTaskExecutionLimit | 1 | Specify the limit for idle executions of a receive task, not having received any message within its execution. If this limit is reached, the task will shut down and leave receiving to other executing tasks (in case of dynamic scheduling; see the "maxConcurrentConsumers" setting). |
listenerConnectionFactory | null | The JMS connection factory used for consuming messages |
maxConcurrentConsumers | 1 | Specifies the maximum number of concurrent consumers |
maxMessagesPerTask | 1 | The number of messages per task |
messageConverter | null | The Spring Message Converter |
messageIdEnabled | true | When sending, should message IDs be added |
messageTimestampEnabled | true | Should timestamps be enabled by default on sending messages |
priority | -1 | Values of > 1 specify the message priority when sending, if the explicitQosEnabled property is specified |
receiveTimeout | none | The timeout when receiving messages |
recoveryInterval | none | The recovery interval |
serverSessionFactory | null | The JMS ServerSessionFactory if you wish to use ServerSessionFactory for consumption |
subscriptionDurable | false | Enabled by default if you specify a durableSubscriberName and a clientId |
taskExecutor | null | Allows you to specify a custom task executor for consuming messages |
templateConnectionFactory | null | The JMS connection factory used for sending messages |
timeToLive | null | Is a time to live specified when sending messages |
transacted | false | Is transacted mode used for sending/receiving messages? |
transactionManager | null | The Spring transaction manager to use |
transactionName | null | The name of the transaction to use |
transactionTimeout | null | The timeout value of the transaction if using transacted mode |
useVersion102 | false | Should the old JMS API be used |
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. Consuming messages removes (or updates) entities in the database.
jpa:entityClassName
Name | Default Value | Description |
The mail: component provides access to Email via Spring's Mail support and the underlying JavaMail system
pop://[user-info@]host[:port][?password=somepwd] imap://[user-info@]host[:port][?password=somepwd] smtp://[user-info@]host[:port][?password=somepwd]
which supports either POP, IMAP or SMTP underlying protocols.
Property | Description |
host | the host name or IP address to connect to |
port | the TCP port number to connect on |
user-info | the user name on the email server |
password | the users password to use |
The mina: component is a transport for working with Apache MINA
mina:tcp://hostname[:port] mina:udp://hostname[:port] mina:multicast://hostname[:port]
Name | Default Value | Description |
The mock: component provides a powerful declarative testing mechanism which is similar to jMock in that it allows declarative expectations to be created on an endpoint up front, then a route used, then the expectations can be asserted in a test case to ensure the routing rules and processors worked as expected.
mock:someName
Where someName can be any string to uniquely identify the endpoint
Here's quick example of MockEndpoint in use, asserting the number of messages which are expected during a test run
MockEndpoint resultEndpoint = context.resolveEndpoint("mock:foo", MockEndpoint.class); resultEndpoint.expectedMessageCount(2); // send some messages ... // now lets assert that the mock:foo endpoint received 2 messages resultEndpoint.assertIsSatisfied();
You can see from the javadoc of MockEndpoint the various helper methods you can use. You can use other methods such as
Here's another example
resultEndpoint.expectedBodiesReceived("firstMessageBody", "secondMessageBody", "thirdMessageBody");
Or you could add an expectation on the headers or content of a specific message. For example
resultEndpoint.message(0).header("foo").isEqualTo("bar");
There are some examples of the Mock endpoint in use in the camel-corecore processor tests.
The pojo: component binds PojoExchanges to method invocations on Java Objects.
pojo:someName
Where someName can be any string to uniquely identify the endpoint
Object instance that can receive invocations, must be explicitly registered with the PojoComponent.
PojoComponent component = (PojoComponent)camelContext.getComponent("pojo"); component.addService("bye", new SayService("Good Bye!"));
Once an endpoint has been registered, you can build Camel routes that use it to process exchanges.
// lets add simple route camelContext.addRoutes(new RouteBuilder() { public void configure() { from("direct:hello").to("pojo:bye"); } });
A pojo: endpoint cannot be defined as the input to the route. Consider using a direct: or queue: endpoint as the input for a PojoExchange. You can use the createProxy() methods on PojoComponent to create a proxy that will generate PojoExchanges and send them to any endpoint:
Endpoint endpoint = camelContext.getEndpoint("direct:hello"); ISay proxy = PojoComponent.createProxy(endpoint, ISay.class); String rc = proxy.say(); assertEquals("Good Bye!", rc);
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).
quartz://timerName?parameters quartz://groupName/timerName?parameters quartz://groupName/timerName/cronExpression
You can configure the Trigger and JobDetail using the parameters
Property | Description |
trigger.repeatCount | How many times should the timer repeat for? |
trigger.repeatInterval | The amount of time in milliseconds between repeated triggers |
job.name | Sets the name of the job |
For example the following routing rule will fire 2 timer events to the endpoint mock:results
from("quartz://myGroup/myTimerName?trigger.repeatInterval=2&trigger.repeatCount=1").to("mock:result");
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
from("quartz://myGroup/myTimerName/0/0/12/*/*/$").to("activemq:Totally.Rocks");
which is equivalent to using the cron expression
0 0 12 * * ?
The following table shows the URI character encodings we use to preserve valid URI syntax
URI Character | Cron character |
'/' | ' ' |
'$' | '?' |
The queue: component provides asynchronous SEDA behaviour so that consumers are invoked in a seperate thread pool to the producer within the same JVM. Note this component has nothing to do with JMS, if you want a distributed SEA then try using either JMS or ActiveMQ or even MINA
queue:someName
Where someName can be any string to uniquely identify the endpoint
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.
rmi://rmi-regisitry-host:rmi-registry-port/registry-path
For example:
rmi://localhost:1099/path/to/service
To call out to an existing RMI service registered in an RMI registry, create a Route similar to:
from("pojo:foo").to("rmi://localhost:1099/foo");
To bind an existing camel processor or service in an RMI registry, create a Route like:
RmiEndpoint endpoint= (RmiEndpoint) endpoint("rmi://localhost:1099/bar"); endpoint.setRemoteInterfaces(ISay.class); from(endpoint).to("pojo:bar");
Notice that when binding an inbound RMI endpoint, the Remote interfaces exposed must be specified.
The timer: component derives from the POJO component to provide timed events. You can only consume events from this endpoint. It produces POJO exchanges that send a Runnable.run() method invocation.
timer:name?options
Where options is a query string that can specify any of the following parameters:
Name | Default Value | Description |
time | The date/time that the (first) event should be generated. | |
period | -1 | If set to greater than 0, then generate periodic events every period milliseconds |
delay | -1 | The number of milliseconds to wait before the first event is generated. Should not be used in conjunction with the time parameter. |
fixedRate | false | Events take place at approximately regular intervals, separated by the specified period. |
daemon | true | Should the thread associated with the timer endpoint be run as a daemon. |
To setup a route that generates an event every 500 seconds:
from("timer://foo?fixedRate=true&delay=0&period=500").to("pojo:bar");
Note that the "bar" pojo registered should implement Runnable.
The xmpp: component implements an XMPP (Jabber) transport.
xmpp:hostname[:port][/room]
The component supports both room based and private person-person conversations