 |  |  |
| | |
Version 2.1
Copyright © 2012 FuseSource Corp. All rights reserved.
Updated: 09 Oct 2012
Table of Contents
List of Tables
List of Examples
Table 1.1 summarizes the Apache Camel endpoints available when using Fuse IDE.
Table 1.1. Apache Camel Endpoints
| Component | Endpoint URI | Description |
|---|---|---|
| ActiveMQ | activemq:[queue:|topic:] | Connects to JMS destinations using Apache ActiveMQ. |
| ActiveMQ Journal | activemq.journal: | Uses ActiveMQ's fast disk journaling implementation to store message bodies in a rolling log file. |
| AMQP | amqp:[queue:|topic:] | Connects to messaging systems using the AMQP protocol. |
| Atom | atom:// | Connects to or publishes Atom feeds using Apache Abdera. |
| Bean | bean: | Uses the Bean Binding to bind message exchanges to beans in the Registry. Can also be used for exposing and invoking POJOs. |
| Bean Validation | bean-validator: | Validates the payload of a message using the Java Validation API (JSR 303 and JAXP Validation) and its reference implementation Hibernate Validator. |
| Browse | browse:Name | Provides a simple BrowsableEndpoint which can be useful for testing,
visualisation tools or debugging. The exchanges sent to the endpoint are all available
to be browsed. |
| Cache | cache:// | Enables you to perform caching operations using EHCache as the cache implementation. |
| Class | class: | Uses the Bean Binding to bind message exchanges to beans in the Registry. Is also used for exposing and invoking POJOs. |
| Cometd | cometd:// | Supports the Jetty implementation of the cometd/bayeux protocol. |
| Crypto |
| Signs and verifies exchanges using the Signature Service of the Java Cryptographic Extension. |
| CXF | cxf:// | Uses Apache CXF for Web services integration. |
| CXF Bean | cxf: | Proceess the exchange using a JAX-WS or JAX-RS annotated bean from the registry. |
| CXFRS | cxfrs:bean: | Uses Apache CXF to connect to JAX-RS services hosted in Apache CXF. |
| DataSet | dataset: | Provides a way to create large numbers of messages for sending to components or asserting that they are consumed correctly. |
| Db4o | db4o:// | For using a db4o datastore as a queue via the db4o library. |
| Direct | direct: | Ensures direct invocation of the consumer from the producer so that single threaded in-VM invocation is performed. |
| Esper | esper:name | Supports using the Esper Library for Event Stream Processing. |
| Event |
| Works with Spring ApplicationEvents. |
| Exec | exec:// | Executes system commands. |
| File | file:// | Sends messages to a file or polls a file or directory. |
| FIX | fix:// | Sends or receives messages using the FIX protocol. |
| Flatpack | flatpack:[fixed|delim]: | Processes fixed width or delimited files or messages using the FlatPack library. |
| Freemarker | freemarker: | Generates a response using a Freemarker template. |
| FTP2 | ftp://[ | Sends and receives files over FTP. |
| GAuth | gauth:// | Implements a Google-specific OAuth consumer for Web applications. |
| GHTTP |
| Provides connectivity to the GAE URL fetch service and can also be used to receive messages from servlets. |
| GLogin | glogin:// | Allows Apache Camel applications outside Google App Engine (GAE) to programmatically login to GAE applications. |
| GMail |
| Sends e-mails via the GAE mail service. |
| GTask | gtask:// | Supports asynchronous message processing on GAE using the task queueing service as a message queue. |
| HDFS | hdfs:// | Reads from and writes to HDFS file systems. |
| Hibernate | hibernate://
| Uses a database as a queue via the Hibernate library. |
| HTTP | http:// | Calls out to external HTTP servers. |
| HTTP4 | http4:// | Calls out to external HTTP servers using the Apache HttpClient 4.x. |
| iBATIS | ibatis: | Performs a query, poll, insert, update or delete in a relational database using Apache iBATIS. |
| IMap | imap://[ | Receives e-mail using IMAP. |
| IRC | irc: | Uses IRC communication. |
| JavaSpace | javaspace:jini:// | Sends and receives messages through JavaSpace. |
| JBI |
| Integrates with JBI endpoints. |
| JCR | jcr:// | Stores messages in a JCR (JSR-170) compliant repository like Apache Jackrabbit. |
| JDBC | jdbc: | Performs JDBC queries and operations. |
| Jetty | jetty:http:// | Exposes services over HTTP. |
| Jing |
| Validates the payload of a message using RelaxNG or RelaxNG compact syntax. |
| JMS | jms:[temp:][queue:|topic:] | Connects to generic JMS providers. |
| JPA | jpa:[ | Uses a database as a queue via the JPA specification for working with OpenJPA, Hibernate or TopLink. |
| JT400 | jt400:// | Integrates with data queues on an AS/400 (aka System i, IBM i, i5, ...) system. |
| Language | language:// | Executes Languages scripts. |
| LDAP | ldap: | Performs searches on LDAP servers. |
| List | list: | Provides a simple BrowsableEndpoint which can be useful for testing,
visualisation tools or debugging. The exchanges sent to the endpoint are all available to
be browsed. |
| Log | log: | Uses Jakarta Commons Logging to log the message exchange to some underlying logging system like log4j. |
| Lucene |
| Uses Apache Lucene to perform Java-based indexing and full text based searches using advanced analysis/tokenization capabilities. |
| MINA |
| Works with Apache MINA. |
| Mock | mock: | Creates mock endpoints for testing routes and mediation rules. |
| MSMQ | msmq: | Sends and receives messages with Microsoft Message Queuing. |
| MSV | msv: | Validates the payload of a message using the MSV Library. |
| Nagios | nagios:// | Sends passive checks to Nagios using JSendNSCA. |
| Netty |
| Works with TCP and UDP protocols using Java NIO based capabilities offered by the JBoss Netty community project. |
| NMR | nmr: | Supports OSGi integration when working with Fuse ESB Enterprise. Enables you to specify the URI of a ServiceMix endpoint. |
| POP | pop3://[ | Receives e-mail using POP3 and JavaMail. |
| Printer |
| Directs payloads on a route to a printer. |
| Properties | properties:// | Facilitates using property placeholders directly in endpoint URI definitions. |
| Quartz |
| Provides for scheduled delivery of messages using the Quartz scheduler. |
| Quickfix |
| Sends and receives FIX messages. |
| Ref | ref: | Looks up existing endpoints bound in the Registry. |
| Restlet | restlet: | Consumes and produces RESTful resources using Restlet. |
| RMI | rmi:// | Works with RMI. |
| RSS | rss: | Consumes RSS feeds using ROME. |
| RNC | rnc: | Validates the payload of a message using RelaxNG Compact Syntax. |
| RNG | rng: | Validates the payload of a message using RelaxNG. |
| Scalate | scalate: | Transforms message using Scalate templates. |
| SEDA | seda: | Delivers messages to a
java.util.concurrent.BlockingQueue. This is useful when
creating SEDA style processing pipelines within the same CamelContext. |
| SERVLET | servlet:// | Provides HTTP based endpoints for consuming HTTP requests that arrive at a HTTP endpoint and this endpoint is bound to a published Servlet. |
| SFTP | sftp://[ | Sends and receives files over SFTP. |
| SIP | smpp:// | Sends and receives SMS through Short Messaging Service Center using the JSMPP library. |
| SMPP |
| Publish/Subscribe communication capability using the Telecom SIP protocol. |
| SMTP | smtp://[ | Sends e-mail using SMTP and JavaMail. |
| SNMP | snmp:// | Polls SNMP capable devices or receive traps. |
| Spring Integration | spring-integration: | Bridges Camel and Spring Integration. |
| Spring Web Services | spring-ws:[ | Client-side support for accessing web services, and server-side support for creating your own contract-first web services using Spring Web Services. |
| SQL | sql: | Performs SQL queries using JDBC. |
| Stream | stream:[in|out|err|header][? | Reads or writes to an input/output/error/file stream. |
| String Template | string-template: | Generates a response using a String Template. |
| Test | test: | Creates a Mock endpoint which expects to receive all the message bodies that could be polled from the given underlying endpoint. |
| Timer | timer: | Creates a timer endpoint. |
| Validation | validator: | Validates the payload of a message using XML Schema and JAXP Validation. |
| Velocity | velocity: | Generates a response using an Apache Velocity template. |
| VM | vm: | Deliver messages to a java.util.concurrent.BlockingQueue,
useful when creating SEDA style processing pipelines within the same JVM. |
| XMPP | xmpp: | Works with XMPP and Jabber. |
| XQuery | xquery: | Generates a response using an XQuery template. |
| XSLT | xslt: | Transforms a message using an XSLT script. |
CXF — uses Apache CXF to interact with JAX-WS Web services
The CXF component provides integration with Apache CXF for connecting to JAX-WS services hosted in Apache CXF.
CXF endpoints support two URI formats:
Referencing the endpoint by the service's bean ID
cxf:bean:beanID[?options]
Referencing the endpoint by the service's address
cxf://someAddress[?options]
Maven users will need to add a dependency on camel-cxf to their poms as
shown in Example 2.1.
Example 2.1. Apache CXF dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cxf</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>If you want to learn about Apache CXF dependencies, see the WHICH-JARS text file.
Table 2.1 lists the options for a CXF endpoint.
Table 2.1. Apache CXF options
| Name | Default Value | Description |
|---|---|---|
wsdlURL | determined from endpoint address | Specifies the location of the WSDL. |
serviceClass |
Specifies the name of the SEI (Service Endpoint Interface) class. The SEI class can have, but does not require, JSR181 annotations. This option is required when
It is possible to use When a Apache CXF endpoint is used in a | |
serviceName | Specifies the QName of the service being implemented. It maps to
wsdl:service@name. | |
portName | Specifies the QName of the port for the service being implemented. It maps to
wsdl:port@name. | |
dataFormat | POJO |
Specifies the message data format the CXF endpoint supports. Valid values are:
|
relayHeaders | true | Specifies whether the endpoint relays headers along the route. This option is
only valid when dataFormat is set to POJO. |
wrapped | false | Specifies whether the endpoint producer invokes wrapped operations. |
wrappedStyle | false | Specifies if the endpoint uses the document-literal wrapped style. |
setDefaultBus | false | Specifies whether to use the default Apache CXF bus for this endpoint. |
bus | Specifies a reference to a bus object in the registry using the
# notation. The referenced bus is used in place of the default
bus. | |
cxfBinding | Specifies a reference to a binding object in the registry using the
# notation. The referenced binding is used in place of the
default binding. | |
headerFilterStrategy | Specifies a reference to an instance of
org.apache.camel.spi.HeaderFilterStrategy in the
registry using the # notation. The referenced instance is used in
place of the default header filter strategy. | |
loggingFeatureEnabled | false | Specifies if the Apache CXF logging feature is enabled. |
defaultOperationName | Specifies the default operationName that will be used by the CxfProducer which invokes the remote service. | |
defaultOperationNameSpace | Specifies the default operationNamespace that will be used by the CxfProducer which invokes the remote service. | |
synchronous | false | Specifies if the endpoint will use Apache Camel's synchronous APIs. |
publishedEndpointUrl | Override the endpointUrl that is published from the WSDL accessed with
service's URL plus ?wsdl. |
CXF Bean — allows other Apache Camel endpoints to send exchanges and invoke Web service bean objects
The CXF Bean component allows other Apache Camel endpoints to send exchanges and invoke JAX-WS or JAXRS annotated service beans.
![[Note]](imagesdb/note.gif) | Note |
|---|---|
The CXF Bean component works similarly to the Bean component. |
The URI format for a CXF Bean endpoint is:
cxfbean:serviceBeanRef[?options]
| Note |
|---|---|
If |
Maven users will need to add a dependency on camel-cxf to their poms as
shown in Example 2.2.
Example 2.2. Apache CXF dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cxf</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>If you want to learn about Apache CXF dependencies, see the WHICH-JARS text file.
Table 2.2 lists the options for a CXF Bean endpoint.
Table 2.2. CXF Bean options
| Name | Default Value | Description |
|---|---|---|
cxfBeanBinding | Specifies a CXF bean binding using the # notation. The
referenced object must be an instance of
org.apache.camel.component.cxf.cxfbean.CxfBeanBinding. | |
bus | Specifies a reference to a bus object in the registry using the
# notation. The referenced bus is used in place of the default
bus. | |
headerFilterStrategy | Specifies a reference to an instance of
org.apache.camel.spi.HeaderFilterStrategy in the
registry using the # notation. The referenced instance is used in
place of the default header filter strategy. | |
setDefaultBus | false | Specifies whether to use the default Apache CXF bus for this endpoint. |
populateFromClass | true | Specifies if the wsdlLocation annotation on the POJO is ignored. |
providers | Sets the providers for a CXFRS endpoint. |
Table 2.3 lists the headers used by a CXF Bean endpoint.
Table 2.3. CXF Bean headers
| Name | Required | Type | Default Value | In/Out | Description |
|---|---|---|---|---|---|
| CamelHttpCharacterEncoding | No | String | In | Specifies the character encoding of the message. | |
| Content-Type | No | String | \**/*\* | In | Specifies the content type of the message. |
| CamelHttpBaseUri | Yes | String | The Endpoint URI of the source endpoint in the Camel exchange | In | Specifies the scheme, host and port portion of the request URI. The value of this header will be set in the CXF message as the Message.BASE_PATH property. It is needed by Apache CXF JAX-RS processing. |
| CamelHttpPath | Yes | String | In | Specifies the request URI's path. | |
| CamelHttpMethod | Yes | String | In | Specifies the RESTful request verb. | |
| CamelHttpResponseCode | No | Integer | Out | Specifies the HTTP response code. |
CXF REST — provides integration for linking with JAX-RS based RESTful services
CXF REST endpoints support two URI formats:
cxfrs://address?options
Where address represents the CXF endpoint's address
cxfrs:bean:rsEndpointWhere rsEndpoint represents the Spring bean's name which
represents the CXFRS client or server
Maven users will need to add a dependency on camel-cxf to their poms as
shown in Example 2.3.
Example 2.3. Apache CXF dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-cxf</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>If you want to learn about Apache CXF dependencies, see the WHICH-JARS text file.
Table 2.4 lists the options for a CXF REST endpoint.
Table 2.4. CXF REST options
| Option | Default Value | Description |
|---|---|---|
resourceClasses | Specifies the resource classes you want to export as REST service. | |
httpClientAPI | true | Specifies if the CxfRsProducer will use the
HttpClientAPI to invoke the service. |
synchronous | false | Specifies if the CxfRsConsumer uses sync or async API
to do the underlying work. |
throwExceptionOnFailure | true | Specifies if the CxfRsProducer inspects return codes and will
generate an exception if the return code is larger than 207. |
You can also configure the CXF REST endpoint through the Spring configuration.
ActiveMQ Journal — stores messages in rolling log file for later processing
The ActiveMQ Journal Component allows messages to be stored in a rolling log file and then consumed from that log file. The journal aggregates and batches up concurrent writes so that the overhead of writing and waiting for the disk sync is relatively constant, regardless of how many concurrent writes are being done. Therefore, this component supports and encourages you to use multiple concurrent producers to the same journal endpoint.
Each journal endpoint uses a different log file and therefore write batching (and the associated performance boost) does not occur between multiple endpoints.
This component only supports one active consumer on the endpoint. After the message is processed by the consumer's processor, the log file is marked and only subsequent messages in the log file will get delivered to consumers.
The URI format for an ActiveMQ Journal endpoint is:
activemq.journal:directoryName[?options]directoryName specifies the name of the directory in which the
journal is stored. For example, to send to a journal located in the
/tmp/data directory you would use the following URI:
activemq.journal:/tmp/data
Table 3.1 lists the options available when using an ActiveMQ Journal endpoint.
Table 3.1. ActiveMQ Journal optionss
| Name | Default Value | Description |
|---|---|---|
syncConsume | false | If set to true, when the journal is marked after a message
is consumed, the endpoint wait until the operating system has verified the mark
update is safely stored on disk. |
syncProduce | true | If set to true, wait until the operating system has verified
the message is safely stored on disk. |
The consumer of a Journal endpoint generates DefaultExchange objects with
the In message set as follows:
journal header: set to the endpoint URI of the journal the message came
from.
location header: location: set to a Location
object which identifies where the recored was stored on disk.
Message body: set to a ByteSequence, which contains the byte array data of
the stored message.
The producer to a Journal endpoint expects an exchange with an In message
where the body can be converted to a ByteSequence or a byte[].
File — provides access to file systems
The File component provides access to file systems, allowing files to be processed by any other Apache Camel components or messages from other components to be saved to disk.
The URI format for a file endpoint is one of:
file:directoryName[?options] file://directoryName[?options]
Table 3.2 list the options that can be set on any file endpoint.
Table 3.2. Common file options
| Name | Default Value | Description |
|---|---|---|
autoCreate
| true
| Automatically create missing directories in the file's pathname. For the file consumer, that means creating the starting directory. For the file producer, it means the directory to where the files should be written. |
bufferSize
| 128kb | Write buffer sized in bytes. |
fileName
| null
| Use an expression language to dynamically set the filename. For consumers,
it's used as a filename filter. For producers, it's used to evaluate the filename
to write. If an
expression is set, it take precedence over the CamelFileName header.
(Note: The header itself can also be an expression).
The expression options support both
String and Expression types. If the expression is
a String type, it is always evaluated
using the file language. If the expression is an Expression type, the
specified Expression type is
used - this allows you, for instance, to use OGNL expressions.
For the consumer, you can use it to filter filenames, so you can for instance consume
today's file using the file language syntax:
mydata-${date:now:yyyyMMdd}.txt. |
flatten
| false
| Flatten is used to flatten the file name path to strip any leading paths, so it's just
the file name. This allows you to consume recursively into sub-directories, but when you
eg write the files to another directory they will be written in a single directory.
Setting this to true on the producer enforces that any file name
recived in CamelFileName header will be stripped for any leading paths.
|
charset
| null
| Specifies the encoding of the file, and camel will set the Exchange.CHARSET_NAME
property with the value. |
Table 3.3 list the options that can be set on a file consuming endpoint.
Table 3.3. File consumer options
| 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
| Set to true to use fixed delay between pools, otherwise fixed rate
is used. See ScheduledExecutorService in JDK for details. |
recursive
| false
| If a directory, will look for files in all the sub-directories as well. |
delete
| false
| If true, the file will be deleted after it is processed |
noop
| false
| If true, the file is not moved or deleted in any way. This option is
good for readonly data, or for ETL type requirements. If
noop=true, Apache Camel will set idempotent=true as
well, to avoid consuming the same files over and over again. |
preMove
| null
| Use an expression to dynamically set the filename when moving it
before processing. For example, to move in-progress
files into the order directory set this value to
order. |
move
| .camel
| Use an expression to dynamically set the filename when moving it after processing. To move files into a .done
subdirectory just enter .done. |
moveFailed
| null
| Use an expression to dynamically set the filename when moving failed files after processing. To move files into a error
subdirectory just enter error. Note:
When moving the files to another location it can/will handle the error when you move it to another location so Apache Camel cannot
pick up the file again. |
include
| null
| Is used to include files, if filename matches the regex pattern. |
exclude
| null
| Is used to exclude files, if filename matches the regex pattern. |
idempotent
| false
| Option to use the Idempotent Consumer EIP pattern
to let Apache Camel skip already processed files. Will by default use a memory based LRUCache
that holds 1000 entries. If noop=true then idempotent will be enabled
as well to avoid consuming the same files over and over again. |
idempotentRepository
| null
| Pluggable repository as a
org.apache.camel.processor.idempotent.MessageIdRepository class.
Will by default use MemoryMessageIdRepository if none is specified and
idempotent is true. |
inProgressRepository
| memory
| Pluggable in-progress repository as a
org.apache.camel.processor.idempotent.MessageIdRepository class. The in-progress
repository is used to account the current in progress files being consumed. By default a
memory based repository is used. |
filter
| null
| Pluggable filter as a
GenericFileFilter class. Will skip
files if filter returns false in its accept()
method. Apache Camel also ships with an ANT path matcher
filter in the camel-spring component. More details in section below.
|
sorter
| null
| Pluggable sorter as a java.util.Comparator<org.apache.camel.component.file.GenericFile> class. |
sortBy
| null
| Built-in sort using the File Language. Supports nested sorts, so you can have a sort by file name and as a 2nd group sort by modified date. See sorting section below for details. |
readLock
| markerFile
|
Used by consumer, to only poll the files if it has exclusive read-lock on the file (i.e. the file is not in-progress or being written). Apache Camel will wait until the file lock is granted. The
|
readLockTimeout
| 0
| Optional timeout in milliseconds for the read-lock, if supported by the read-lock. If
the read-lock could not be granted and the timeout triggered, then Apache Camel will skip the
file. At next poll Apache Camel, will try the file again, and this time maybe the read-lock
could be granted. Currently fileLock, changed and
rename support the timeout. |
exclusiveReadLockStrategy
| null
| Pluggable read-lock as an implementation of the
GenericFileExclusiveReadLockStrategy interface. |
processStrategy
| null
| A pluggable
GenericFileProcessStrategy allowing
you to implement your own readLock option or similar. Can also be used
when special conditions must be met before a file can be consumed, such as a special
ready file exists. If this option is set then the
readLock option does not apply. |
maxMessagesPerPoll
| 0
| An integer that defines the maximum number of messages to gather per poll. By default, no maximum is set. Can be used to set a limit of e.g. 1000 to avoid having the server read thousands of files as it starts up. Set a value of 0 or negative to disabled it. |
startingDirectoryMustExist
| false
| Whether the starting directory must exist. Mind that the autoCreate option
is default enabled, which means the starting directory is normally auto-created if it
doesn't exist. You can disable autoCreate and enable this to ensure the
starting directory must exist. Will throw an exception, if the directory doesn't exist.
|
directoryMustExist
| false
| Similar to startingDirectoryMustExist but this applies during polling
recursive sub-directories. |
Table 3.4 list the options that can be set on a file producing endpoint.
Table 3.4. File producer options
| Name | Default Value | Description |
|---|---|---|
fileExist
| Override
|
Specifies what to do if a file with the same name already exists. The following values can be specified:
|
tempPrefix
| null
| This option is used to write the file using a temporary name and then, after the write is complete, rename it to the real name. Can be used to identify files being written and also avoid consumers (not using exclusive read locks) reading in progress files. Is often used by FTP when uploading big files. |
tempFileName
| null
| The same as
tempPrefix option but offering a more fine grained control on the
naming of the temporary filename as it uses the File
Language. |
keepLastModified | false | Specifies if the file will keep the last modified time stamp from
the source file (if any). The Exchange.FILE_LAST_MODIFIED
header is used to store the time stamp. If the time stamp exists and the option is
enabled it will set this time stamp in the exchange header on the written file. |
eagerDeleteTargetFile
| true
| Specifies whether or not to eagerly delete any existing target file.
This option only applies when you use fileExists=Override and
the tempFileName option. |
The following headers are supported by this component:
Table 3.5. File producer headers
| Header | Description |
|---|---|
CamelFileName
| Specifies the name of the file to write (relative to the endpoint directory). The name
can be a String; a String with a File Language or Simple
expression; or an Expression object. If it's
null then Apache Camel will auto-generate a filename based on the message
unique ID. |
CamelFileNameProduced
| The actual absolute filepath (path + name) for the output file that was written. This header is set by Camel and its purpose is providing end-users with the name of the file that was written. |
Table 3.6. File consumer headers
| Header | Description |
|---|---|
CamelFileName
| Name of the consumed file as a relative file path with offset from the starting directory configured on the endpoint. |
CamelFileNameOnly
| Only the file name (the name with no leading paths). |
CamelFileAbsolute
| A boolean option specifying whether the consumed file denotes an
absolute path or not. Should normally be false for relative paths.
Absolute paths should normally not be used but we added to the move option to allow moving
files to absolute paths. But can be used elsewhere as well. |
CamelFileAbsolutePath
| The absolute path to the file. For relative files this path holds the relative path instead. |
CamelFilePath
| The file path. For relative files this is the starting directory + the relative filename. For absolute files this is the absolute path. |
CamelFileRelativePath
| The relative path. |
CamelFileParent
| The parent path. |
CamelFileLength
| A long value containing the file size. |
CamelFileLastModified
| A Date value containing the last modified timestamp of the file.
|
As the file consumer is BatchConsumer it supports batching the files it
polls. By batching it means that Apache Camel will add some properties to the exchange
so you know the number of files polled the current index in that order.
Table 3.7. Exchange properties used by a file consumer
| Property | Description |
|---|---|
CamelBatchSize
| The total number of files that was polled in this batch. |
CamelBatchIndex
| The current index of the batch. Starts from 0. |
CamelBatchComplete
| A boolean value indicating the last exchange
in the batch. Is only true for the last entry. |
This allows you for instance to know how many files exists in this batch and for instance let the Aggregator aggregate this number of files.
FTP/SFTP — provides access to remote file systems over the FTP and SFTP protocols
This component provides access to remote file systems over the FTP and SFTP protocols.
This component uses two different libraries for the actual FTP work. FTP and FTPS uses Apache Commons Net while SFTP uses JCraft JSCH.
The URI format for an FTP endpoint is:
ftp://[username@]hostname[:port]/directoryname[?options] ftps://[username@]hostname[:port]/directoryname[?options]
The URI format for an SFTP endpoint is:
sftp://[username@]hostname[:port]/directoryname[?options]
If no username is provided, then an anonymous login is attempted.
If no port number is provided, Apache Camel will provide default values
according to the protocol:
ftp = 21
sftp = 22
ftps = 21
Table 3.8 lists the options for the FTP component.
Table 3.8. FTP options
| Name | Supported Protocol | Default Value | Description |
|---|---|---|---|
password | FTP, FTPS, SFTP | null
| Specifies the password to use to log in to the remote file system. |
binary | FTP, FTPS, SFTP | false | Specifies the if the files should be treated as binary data. |
disconnect | FTP, FTPS, SFTP | false | Whether or not to disconnect from remote FTP server right after use. Can be used for both consumer and producer. Disconnect will only disconnect the current connection to the FTP server. If you have a consumer which you want to stop, then you need to stop the consumer/route instead. |
localWorkDirectory | FTP, FTPS, SFTP | null
| When consuming, a local work directory can be used to store the remote file content directly in local files, to avoid loading the content into memory. This is beneficial, if you consume a very big remote file and thus can conserve memory. See below for more details. |
passiveMode | FTP | false | Specifies whether to use passive mode connections. |
securityProtocol | FTPS | TLS |
Sets the underlying security protocol.
The following values are defined: |
disableSecureDataChannelDefaults | FTPS | false | Whether or not to disable using
default values for execPbsz and execProt when using
secure data transfer. You can set this option to true if you want to be
in absolute full control what the options execPbsz and
execProt should be used. |
execProt | FTPS | null
|
Will by default use option
|
execPbsz | FTPS | null | This option specifies the buffer
size of the secure data channel. If option useSecureDataChannel has
been enabled and this option has not been explicit set, then value 0 is
used. |
isImplicit | FTPS | false
| Specifies if the security mode is implicit. |
knownHostsFile | SFTP | null
| Sets the known_hosts
file, so that the SFTP endpoint can do host key verification. |
privateKeyFilePassphrase | SFTP | null
| Set the private key file passphrase to that the SFTP endpoint can do private key verification. |
privateKeyFilePassphrase | SFTP | null
| Set the private key file passphrase to that the SFTP endpoint can do private key verification. |
strictHostKeyChecking | SFTP | no
| Sets whether to use strict host key checking. Possible values are: no,
yes and ask. ask does not make
sense to use as Camel cannot answer the question for you as its meant for human
intervention. |
maximumReconnectAttempts | FTP, FTPS, SFTP | 3 | Specifies the maximum reconnect attempts Apache Camel performs when it tries to connect to the remote FTP server. Use 0 to disable this behavior. |
reconnectDelay | FTP, FTPS, SFTP | 1000 | Delay in milliseconds Apache Camel will wait before performing a reconnect attempt. |
connectTimeout | FTP, FTPS, SFTP | 10000 | Specifies the connect timeout in milliseconds. |
soTimeout | FTP, FTPS | null | Specifies the SocketOptions.SO_TIMEOUT value in
milliseconds. |
timeout | FTP, FTPS | 30000 | Specifies the data timeout in milliseconds. |
throwExceptionOnConnectFailed | FTP, FTPS, SFTP | false | Specifies whether or not to thrown an exception if a
successful connection and login could not be establish. This allows a custom
pollStrategy to deal with the exception, for example to stop the
consumer or the likes. |
siteCommand | FTP, FTPS | null
| To execute site commands after successful login. Multiple site commands
can be separated using a new line character (\n). Use help site to see
which site commands your FTP server supports. |
stepwise | FTP, FTPS, SFTP | true | When consuming directories, specifies whether or not to use stepwise mode for traversing the directory tree. Stepwise means that it will CD one directory at a time. |
ftpClient | FTP, FTPS | null | Allows you to use a custom
org.apache.commons.net.ftp.FTPClient instance. |
ftpClientConfig | FTP, FTPS | null | Allows you to use a custom
org.apache.commons.net.ftp.FTPClientConfig instance. |
ftpClient.trustStore.file | FTPS | null | Sets the trust store file, so that the FTPS client can look up for trusted certificates. |
ftpClient.trustStore.type | FTPS | JKS | Sets the trust store type. |
ftpClient.trustStore.algorithm | FTPS | SunX509 | Sets the trust store algorithm. |
ftpClient.trustStore.password | FTPS | null | Sets the trust store password. |
ftpClient.keyStore.file | FTPS | null
| Sets the key store file, so that the FTPS client can look up for the private certificate. |
ftpClient.keyStore.type
| FTPS | JKS
| Sets the key store type. |
ftpClient.keyStore.algorithm
| FTPS | SunX509
| Sets the key store algorithm. |
ftpClient.keyStore.password
| FTPS | null
| Sets the key store password. |
ftpClient.keyStore.keyPassword
| FTPS | null
| Sets the private key password. |
The FTP and FTPS protocols can support additional configuration options provided by
the Apache Commons FTP layer used to implement them. To specify these additional options you
use the ftpClient. or ftpClientConfig. prefix. The prefixes
correspond to the Apache Commons FTPClient and the Apache Commons
FTPClientConfig objects.
If you do not like having many and long configuration in the URL you can configure the
ftpClient or the ftpClientConfig in the Spring
configuration as shown in Example 3.1.
Example 3.1. Configuring the FTP client in XML
<bean id="myConfig" class="org.apache.commons.net.ftp.FTPClientConfig"> <property name="lenientFutureDates" value="true"/> <property name="serverLanguageCode" value="fr"/> </bean> ... <camelContext> <route id="myroute"> <from uri="ftp://foo@myserver?password=secret&ftpClientConfig=#myConfig" /> <to uri="bean:foo" /> </route> ... </camelContext> ...
See the documentation of the Apache Commons FTP FTPClientConfig for possible options and more details. And as well for Apache Commons FTP FTPClient.
Many of the file endpoint options also apply to the FTP/SFTP endpoints. See File.
The following message headers can be used to affect the behavior of the component:
Table 3.9. FTP message headers
| Header | Description |
|---|---|
CamelFileName
| Specifies the output file name (relative to the endpoint directory) to be used for the output message when sending to the endpoint. If this is not present and no expression either, then a generated message ID is used as the filename instead. |
CamelFileNameProduced
| The actual absolute filepath (path + name) for the output file that was written. This header is set by Apache Camel and its purpose is providing end-users the name of the file that was written. |
CamelFileBatchIndex
| Current index out of total number of files being consumed in this batch. |
CamelFileBatchSize
| Total number of files being consumed in this batch. |
CamelFileHost | The remote hostname. |
CamelFileLocalWorkPath
| Path to the local work file, if local work directory is used. |
HDFS — enables you to read and write messages from/to an HDFS file system
HDFS is the distributed file system at the heart of Hadoop. It can only be built using JDK1.6 or later because this is a strict requirement for Hadoop itself. This component is hosted at http://github.com/dgreco/camel-hdfs. We decided to put it temporarily on this github because currently Apache Camel is being built and tested using JDK1.5 and for this reason we couldn't put that component into the Apache Camel official distribution.
The URI format for an HDFS endpoint is:
hdfs://hostname[:port][/path][?options]
The path is treated in the following way:
as a consumer, if it's a file, it just reads the file, otherwise if it represents a directory it scans all the file under the path satisfying the configured pattern. All the files under that directory must be of the same type.
as a producer, if at least one split strategy is defined, the path is considered a
directory and under that directory the producer creates a different file per split named
seg0, seg1, seg2, etc.
Table 3.10 lists the options for HDFS endpoint.
Table 3.10. HDFS options
| Name | Default Value | Description |
|---|---|---|
overwrite
| true
| Specifies if the file can be overwritten. |
bufferSize
| 4096
| Specifies the buffer size used by HDFS. |
replication
| 3
| Specifies the HDFS replication factor. |
blockSize
| 67108864
| Specifies the size of the HDFS blocks in bytes. |
fileType
| NORMAL_FILE
|
Specifies the type of file to use. Valid values are:
See the Hadoop documentation for more information. |
fileSystemType
| HDFS
| It can be LOCAL for local filesystem |
keyType
| NULL
|
Specifies the type for the key in case of sequence or map files. |
valueType
| TEXT
|
Specifies the type for the key in case of sequence or map files. |
splitStrategy
|
A string describing the strategy on how to split the file based on different criteria. | |
openedSuffix
| opened
|
When a file is opened for reading/ writing the file is renamed with this suffix to avoid to read it during the writing phase. |
readSuffix
| read
|
Once the file has been read is renamed with this suffix to avoid to read it again. |
initialDelay
| 0
|
Specifies how long a consumer will wait, in milliseconds, before starting to scanning the directory. |
delay
| 0
|
Specifies the interval, in milliseconds, between the directory scans. |
pattern
| *
|
The pattern used for scanning the directory |
chunkSize
| 4096
|
When reading a normal file, this is split into chunks producing a message per chunk |
GAuth — implement a Google-specific OAuth consumer
The GAuth component is used by web applications to implement a Google-specific OAuth consumer. Although this component belongs to the Camel Components for Google App Engine (GAE), it can also be used to OAuth-enable non-GAE web applications. For a detailed description of Google's OAuth implementation refer to the Google OAuth API reference.
The URI format for a GAuth endpoint is:
gauth://name[?options]
name can be either authorize or
upgrade. An authorize endpoint is used to obtain an
unauthorized request token from Google and to redirect the user to the authorization page. The
upgrade endpoint is used to process OAuth callbacks from Google and to
upgrade an authorized request token to a long-lived access token.
Maven users will need to add a dependency on camel-gae to their poms as
shown in Example 4.1.
Example 4.1. GAuth dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-gae</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 4.1 lists the options for a GAuth endpoint.
Table 4.1. GAuth options
| Name | Required | Description |
|---|---|---|
callback | true
[a] | Specifies the URL to where users are redirected after having granted or denied access. |
scope | true
[b]
| Specifies the URL identifying the service(s) to be accessed. To specify more than one scope, list each one separated with a comma. |
consumerKey | true
[c]
| Specifies the domain identifying the web application. This is the domain used
when registering the application with Google. For a non-registered application use
anonymous. |
consumerSecret | if keyLoaderRef is not
specified[c] | Specifies the consumer secret of the web application. The consumer secret is
generated when registering the application with Google. It is needed if the
HMAC-SHA1 signature method shall be used. For a non-registered application use
anonymous. |
keyLoaderRef | if consumerSecret is not
specified[c] |
Specifies a reference to a private key loader in the registry. The
These classes are defined in the org.apache.camel.component.gae.auth package. |
authorizeBindingRef | false | Specifies a reference to a
OutboundBinding<GAuthEndpoint, GoogleOAuthParameters, GoogleOAuthParameters>
in the registry for customizing how an exchange is bound to
GoogleOAuthParameters. This binding is used for the authorization
phase. |
upgradeBindingRef | false | Specifies a reference to a
OutboundBinding<GAuthEndpoint, GoogleOAuthParameters, GoogleOAuthParameters>
in the registry for customizing how an exchange is bound to
GoogleOAuthParameters. This binding is used for the token upgrade
phase. |
[a] can alternatively be set via the
[b] can alternatively be set via [c] can alternatively be set on component-level | ||
The following message headers can be used to affect the behavior of the component:
| Name | Endpoint | Message | Description |
|---|---|---|---|
GAuthAuthorizeBinding.GAUTH_CALLBACK | gauth:authorize | IN | Overrides the callback option. |
GAuthAuthorizeBinding.GAUTH_SCOPE | gauth:authorize | IN | Overrides the scope option. |
GAuthUpgradeBinding.GAUTH_ACCESS_TOKEN | gauth:upgrade | OUT | Contains the long-lived access token. This token should be stored by the applications in context of a user. |
GAuthUpgradeBinding.GAUTH_ACCESS_TOKEN_SECRET | gauth:upgrade | OUT | Contains the access token secret. This token secret should be stored by the applications in context of a user. |
GHTTP — provides connectivity to the GAE URL fetch service but can also be used to receive messages from servlets
The ghttp component provides connectivity to the GAE
URL fetch
service but can also be used to receive messages from servlets. This is achieved by
extending the Servlet component. As a consequence,
GHTTP URI formats and options sets differ on the consumer-side (from) and
producer-side (to).
GHTTP endpoints can use the following URI formates:
| Format | Context | Comment |
|---|---|---|
ghttp:///
| Consumer | See also Servlet component |
ghttp://
| Producer | See also HTTP |
ghttps://
| Producer | See also HTTP |
Maven users will need to add a dependency on camel-gae to their poms as
shown in Example 4.2.
Example 4.2. GHTTP dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-gae</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 4.2 lists the options for a GHTTP endpoint.
Table 4.2. GHTTP options
| Name | Default | Context | Description |
|---|---|---|---|
bridgeEndpoint | true | Producer | Specifies if the Exchange.HTTP_URI header is ignored. |
throwExceptionOnFailure | true | Producer | Specifies if a
org.apache.camel.component.gae.http is thrown when
the response code is >= 400. |
inboundBindingRef | Consumer | Specifies a reference to an
InboundBinding<GHttpEndpoint, HttpServletRequest, HttpServletResponse>
in the registry for customizing the binding of an exchange to the Servlet API. The
referenced binding is used as post-processor to
org.apache.camel.component.http.HttpBinding. | |
outboundBindingRef | Producer | Specifies a reference to an
InboundBinding<GHttpEndpoint, HttpServletRequest, HttpServletResponse>
in the registry for customizing the binding of an exchange to the
URLFetchService. |
On the consumer-side, all options of the Servlet endpoint are supported.
On the producer side, the following headers of the HTTP endpoint are supported.
| Name | Type | Description |
|---|---|---|
Content-Type | String | Specifies the HTTP content type. This header is populated on both the IN and OUT message to provide a content type. |
Content-Encoding | String | Specifies the HTTP content encoding. This header is populated on both the IN and OUT message to provide a content encoding. |
CamelHttpMethod | String | Specifies the HTTP method to execute. Can be one of
GET, POST, PUT or
DELETE. If not set, POST will be used if
the message body is not null, GET
otherwise. |
CamelHttpQuery | String | Overrides the query part of the endpoint URI or
HTTP_URI. The query string must be in decoded form. |
CamelHttpUri | String | Overrides the default endpoint URI if the bridgeEndpoint option is
set to false. The URI string must be in decoded form. |
CamelHttpResponseCode | int | Specifies the HTTP response code from URL fetch service responses. |
On the consumer-side all headers of the Servlet component headers are supported.
On the producer side the in message body is converted to a
byte[]. The out message body is made available as
InputStream. If the reponse size exceeds 1 megabyte a ResponseTooLargeException is thrown by the URL fetch service (see quotas and limits).
GLogin — allows for programmatic login to GAE applications
The URI format for a GLogin endpoint is:
glogin://hostname[:port][?options]
The hostname is either the internet hostname of a GAE application (e.g.
camelcloud.appspot.com) or the name of the host where the development
server is running (e.g. localhost). The port is
only used when connecting to a development server (i.e. when devMode=true)
and defaults to 8080.
Maven users will need to add a dependency on camel-gae to their poms as
shown in Example 4.3.
Example 4.3. GLogin dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-gae</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 4.3 lists the options for a GLogin endpoint.
Table 4.3. GLogin options
| Name | Default | Required | Description |
|---|---|---|---|
clientName | apache-camel-2.x | false | Specifies a client name using recommended format:
<organization>\-<appname>\-<version>. |
userName | true [a] | Specifies the login username. | |
password | true [b] | Specifies the login password. | |
devMode | false | false | Specifies whether to login to a development server. |
devAdmin | false | false | Specifies if an attempt to login to the development server as an administrator is attempted. |
[a] can alternatively be set via the
[b] can alternatively be set via the
| |||
GLogin endpoints use the following GLoginBinding headers:
| Name | Type | Message | Description |
|---|---|---|---|
GLOGIN_HOST_NAME | String | IN | Overrides the hostname defined in the endpoint URI. |
GLOGIN_USER_NAME | String | IN | Overrides the userName option. |
GLOGIN_PASSWORD
| String
| IN | Overrides the password option. |
GLOGIN_TOKEN
| String
| OUT | Contains the authentication token obtained from Google Accounts. Login to a development server does not set this header. |
GLOGIN_COOKIE
| String
| OUT | Contains the application-specific authorization cookie obtained from Google App Engine (or a development server). |
GMail — supports sending of emails via the GAE mail service
The URI format for a GMail endpoint is one of the following:
gmail://user@gmail.com[?options] gmail://user@googlemail.com[?options]
Maven users will need to add a dependency on camel-gae to their poms as
shown in Example 4.4.
Example 4.4. GMail dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-gae</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 4.4 lists the options for a GMail endpoint.
Table 4.4. GMail options
| Name | Context | Description |
|---|---|---|
to | Producer | Specifies the To-receiver of the email. To specify multiple
recipients use a comma-separated list. |
cc | Producer | Specifies the Cc-receiver of the email. To specify multiple
recipients use a comma-separated list. |
bcc | Producer | Specifies the Bcc-receiver of the email. To specify multiple
recipients use a comma-separated list. |
subject | Producer | Specifies the subject of the email. |
outboundBindingRef | Producer | Specifies a reference to an
OutboundBinding<GMailEndpoint, MailService.Message, void> in the
registry for customizing the binding of an exchange to the mail service. |
GMail producer endpoints use the following GMailBinding headers:
| Name | Type | Description |
|---|---|---|
GMAIL_SUBJECT
| String
| Subject of the email. Overrides subject endpoint
option. |
GMAIL_SENDER
| String
| Sender of the email. Overrides sender definition in endpoint URI. |
GMAIL_TO
| String
| To-receiver(s) of the email. Overrides to endpoint option. |
GMAIL_CC
| String
| Cc-receiver(s) of the email. Overrides cc endpoint option. |
GMAIL_BCC
| String
| Bcc-receiver(s) of the email. Overrides bcc endpoint option. |
GTask — supports asynchronous message processing on GAE by using the task queueing service as message queue
GTask endpoints support asynchronous message processing on GAE by using the task queueing service as message queue. For adding messages to a queue it uses the task queue API. For receiving messages from a queue, it installs an HTTP callback handler. The handler is called by an HTTP POST callback (a web hook) initiated by the task queueing service. Whenever a new task is added to a queue a callback will be sent. The GTask component abstracts from these details and supports endpoint URIs that make message queueing on GAE as easy as message queueing with JMS or SEDA.
Maven users will need to add a dependency on camel-gae to their poms as
shown in Example 4.5.
Example 4.5. GTask dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-gae</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 4.5 lists the options for a GTask endpoint.
Table 4.5. GTask options
| Name | Default Value | Context | Description |
|---|---|---|---|
workerRoot
| worker
| Producer | The servlet mapping for callback handlers. By default, this component requires a
callback servlet mapping of /worker/*. If another servlet mapping is
used e.g. /myworker/* it must be set as option on the producer side:
to("gtask:myqueue?workerRoot=myworker"). |
inboundBindingRef
| reference to GTaskBinding
| Consumer | Reference to an InboundBinding<GTaskEndpoint, HttpServletRequest,
HttpServletResponse> in the registry for
customizing the binding of an Exchange to the Servlet API. The
referenced binding is used as post-processor to
org.apache.camel.component.http.HttpBinding. |
outboundBindingRef
| reference to GTaskBinding
| Producer | Reference to an OutboundBinding<GTaskEndpoint, TaskOptions, void>
in the registry for customizing the binding of an
Exchange to the task queueing service. |
On the consumer-side, all options of the Servlet component are supported.
On the consumer-side all headers of the Servlet component component are supported.
In addition the following GTaskBinding headers are used by on the
consumer-side.
| Name | Type | Description |
|---|---|---|
GTASK_QUEUE_NAME
| String
| Name of the task queue. |
GTASK_TASK_NAME
| String
| Name of the task. |
GTASK_RETRY_COUNT
| int
| Number of callback retries. |
HTTP — provides endpoints for consuming external HTTP resources
The HTTP component provides HTTP based endpoints for consuming external HTTP resources as a client to call external servers using HTTP.
The HTTP component can only send messages to external resources. It should never be used as input into a route. To expose an HTTP endpoint via a HTTP server as input to a route, you can use the Jetty Component.
The URI format for an HTTP endpoint is:
http(s):hostname[:port][/resourceUri][?options]
By default the port is set to 80 for HTTP and to
443 for HTTPS.
Maven users will need to add a dependency on camel-http to their
pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-http</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 5.1 lists the options for an HTTP endpoint.
Table 5.1. HTTP endpoint options
| Name | Default Value | Description |
|---|---|---|
throwExceptionOnFailure | true | Specifies if you want to disable throwing the
HttpOperationFailedException in case of failed
responses from the remote server. This allows you to get all responses regardless of
the HTTP status code. |
bridgeEndpoint | false | Specifies if the HttpProducer ignores the Exchange.HTTP_URI
header, and use the endpoint's URI for request. If the option is true,
HttpProducer and CamelServlet will skip the gzip processing if the
content-encoding is gzip. |
disableStreamCache | false | Specifies if the DefaultHttpBinding copies the request input stream directly into the message body. The default setting is to copy the request input stream into a stream cache and into the message body to support reading the message twice. |
httpBinding | null | Specifies a reference to a
org.apache.camel.component.http.HttpBinding in the registry. |
httpClientConfigurer | null | Specifies a reference to a
org.apache.camel.component.http.HttpClientConfigurer in the registry. |
httpClient. | Specifies options to set on the HttpClientParams. For instance httpClient.soTimeout=5000 will set the
SO_TIMEOUT to 5 seconds. | |
clientConnectionManager | null | Specifies a reference to a custom
org.apache.http.conn.ClientConnectionManager. |
The following authentication options can also be set on the HTTP endpoint:
Table 5.2. HTTP authentication options
| Name | Description |
|---|---|
authMethod |
Specifies the authentication method to use. Supported methods are:
|
authMethodPriority | Specifies the priority of the authentication methods using a comma seperated list. |
authUsername | Specifies the username for authentication. |
authPassword | Specifies the password for authentication. |
authDomain | Specifies the domain for NTML authentication. |
authHost | Specifies an optional host for NTML authentication. |
proxyHost | Specifies the proxy host name. |
proxyPort | Specifies the proxy port number. |
proxyAuthMethod |
Specifies the authentication method to use for connecting to the proxy. Supported methods are:
|
proxyAuthUsername | Specifies the username for proxy authentication. |
proxyAuthPassword | Specifies the password for proxy authentication. |
proxyAuthDomain | Specifies the domain for proxy NTML authentication. |
proxyAuthHost | Specifies the optional host for proxy NTML authentication. |
When using authentication you must provide a value for
either the authMethod or authProxyMethod options.
The following Exchange properties are recognized by HTTP endpoints:
Table 5.3. HTTP Exchange properties
| Name | Type | Description |
|---|---|---|
CamelHttpUri | String | Specifies the URI to call. The value if this header will override the URI set directly on the endpoint. |
CamelHttpPath | String | Specifies the Request URI's path. The header will be used to build the request
URI with the HTTP_URI. If the path is start with /, the HTTP producer
will try to find the relative path based on the HTTP_BASE_URI header or
the exchange.getFromEndpoint().getEndpointUri() method. |
CamelHttpQuery | String | Specifies the URI parameters. The value of this header overrides the URI parameters set directly on the endpoint. |
CamelHttpResponseCode | int | Specifies the HTTP response code from the external server. |
CamelHttpCharacterEncoding | String | Specifies the character encoding. |
Content-Type | String | Specifies the HTTP content type. This header is populated on both the IN and OUT message to provide a content type. |
Content-Encoding | String | Specifies the HTTP content encoding. This header is populated on both the IN and OUT message to provide a content encoding. |
CamelHttpServletRequest | String | Specifies the HttpServletRequest object. |
CamelHttpServletResponse | String | Specifies the HttpServletResponse object. |
CamelHttpProtocolVersion | String | Specifies the HTTP protocol version. If you do not specify the header,
HttpProducer will use the default value HTTP/1.1. |
Apache Camel will store the HTTP response from the external server on the OUT body. All headers from the IN message will be copied to the OUT message, so headers are preserved during routing. Additionally Apache Camel will add the HTTP response headers as well to the OUT message headers.
Apache Camel will handle according to the HTTP response code:
Response code is in the range 100..299, Apache Camel regards it as a success response.
Response code is in the range 300..399, Apache Camel regards it as a redirection response
and will throw a HttpOperationFailedException with the
information.
Response code is 400+, Apache Camel regards it as an external server failure and will
throw a HttpOperationFailedException with the information.
throwExceptionOnFailure can be set to false to prevent
the HttpOperationFailedException from being thrown for
failed response codes. This allows you to get any response from the remote server.
HTTP4 — provides endpoints for consuming external HTTP resources using Apache HttpClient 4.x
The HTTP4 component provides HTTP based endpoints for consuming external HTTP resources as a client to call external servers using HTTP.
The HTTP4 component can only send messages to external resources. It should never be used as input into a route. To expose an HTTP endpoint via a HTTP server as input to a route, you can use the Jetty Component.
![[Important]](imagesdb/important.gif) | HTTP4 vs HTTP |
|---|---|
HTTP4 uses HttpClient 4.x while HTTP uses HttpClient 3.x. |
The URI format for an HTTP4 endpoint is:
http(s)4:hostname[:port][/resourceUri][?options]
By default the port is set to 80 for HTTP and to
443 for HTTPS.
Maven users will need to add a dependency on camel-http4 to their
pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-http4</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 5.4 lists the options for an HTTP4 endpoint.
Table 5.4. HTTP4 endpoint options
| Name | Default | Description |
|---|---|---|
x509HostnameVerifier | BrowserCompatHostnameVerifier
[a]
| Specifies an X509HostnameVerifier[a]
instance in the registry. |
throwExceptionOnFailure | true | Specifies if you want to disable throwing the
HttpOperationFailedException in case of failed
responses from the remote server. This allows you to get all responses regardless
of the HTTP status code. |
bridgeEndpoint | false | Specifies if the HttpProducer ignores the Exchange.HTTP_URI
header, and use the endpoint's URI for request. If the option is true,
HttpProducer and CamelServlet will skip the gzip processing if the
content-encoding is gzip. |
disableStreamCache | false | Specifies if the DefaultHttpBinding copies the request input stream directly into the message body. The default setting is to copy the request input stream into a stream cache and into the message body to support reading the message twice. |
httpBinding | null | Specifies a reference to a HttpBinding[b] in the
registry. |
httpClientConfigurer | null | Specifies a reference to a HttpClientConfigurer
[b] in the registry. |
httpClient. | Specifies options to set on the
BasicHttpParams.
For instance, httpClient.soTimeout=5000 will set the
SO_TIMEOUT to 5 seconds. | |
clientConnectionManager | null | Specifies a custom ClientConnectionManager
[c]. |
transferException | false | Specifies if a producer will throw the received exception if the received
exception was serialized in the response as a
application/x-java-serialized-object content type. |
maxTotalConnections | 200 | Specifies the maximum number of connections. |
connectionsPerRoute | 20 | Specifies the maximum number of connections per route. |
[a] In the package org.apache.http.conn.ssl. [b] In the org.apache.camel.component.http package. [c] In the org.apache.http.conn package. | ||
The following authentication options can also be set on the HTTP4 endpoint:
| Name | Default | Description |
|---|---|---|
username
| null
| Username for authentication. |
password
| null
| Password for authentication. |
domain
| null
| The domain name for authentication. |
host
| null
| The host name authentication. |
proxyHost
| null
| The proxy host name |
proxyPort
| null
| The proxy port number |
proxyUsername
| null
| Username for proxy authentication |
proxyPassword
| null
| Password for proxy authentication |
proxyDomain
| null
| The proxy domain name |
proxyNtHost
| null
| The proxy Nt host name |
The following options can be set on the HttpComponent:
| Name | Default | Description |
|---|---|---|
httpBinding
| null
| To use a custom org.apache.camel.component.http.HttpBinding. |
httpClientConfigurer
| null
| To use a custom org.apache.camel.component.http.HttpClientConfigurer. |
httpConnectionManager
| null
| To use a custom org.apache.commons.httpclient.HttpConnectionManager. |
x509HostnameVerifier
| null
| To use a custom org.apache.http.conn.ssl.X509HostnameVerifier
|
The following Exchange properties are recognized by HTTP4 endpoints:
Table 5.5. HTTP Exchange properties
| Name | Type | Description |
|---|---|---|
CamelHttpUri | String | Specifies the URI to call. The value if this header will override the URI set directly on the endpoint. |
CamelHttpPath | String | Specifies the Request URI's path. The header will be used to build the request
URI with the HTTP_URI. If the path is start with /, the HTTP producer
will try to find the relative path based on the HTTP_BASE_URI header or
the exchange.getFromEndpoint().getEndpointUri() method. |
CamelHttpQuery | String | Specifies the URI parameters. The value of this header overrides the URI parameters set directly on the endpoint. |
CamelHttpResponseCode | int | Specifies the HTTP response code from the external server. |
CamelHttpCharacterEncoding | String | Specifies the character encoding. |
Content-Type | String | Specifies the HTTP content type. This header is populated on both the IN and
OUT message to provide a content type, such as text/html. |
Content-Encoding | String | Specifies the HTTP content encoding. This header is populated on both the IN
and OUT message to provide a content encoding, such as gzip. |
CamelHttpServletRequest | String | Specifies the HttpServletRequest object. |
CamelHttpServletResponse | String | Specifies the HttpServletResponse object. |
CamelHttpProtocolVersion | String | Specifies the HTTP protocol version. If you do not specify the header,
HttpProducer will use the default value HTTP/1.1. |
Camel will store the HTTP response from the external server on the OUT body. All headers from the IN message will be copied to the OUT message, so headers are preserved during routing. Additionally Camel will add the HTTP response headers as well to the OUT message headers.
Apache Camel will handle according to the HTTP response code:
Response code is in the range 100..299, Apache Camel regards it as a success response.
Response code is in the range 300..399, Apache Camel regards it as a redirection response
and will throw a HttpOperationFailedException with the
information.
Response code is 400+, Apache Camel regards it as an external server failure and will
throw a HttpOperationFailedException with the information.
![[Tip]](imagesdb/tip.gif) | Tip |
|---|---|
The option, |
Jetty — provides endpoints for consuming HTTP requests
The Jetty component provides HTTP-based endpoints for consuming HTTP requests. That is, the Jetty component behaves as a simple Web server.
The Jetty component only supports consumer endpoints. Therefore a Jetty endpoint URI should be used only as the input for a Apache Camel route. To issue HTTP requests against other HTTP endpoints, use the HTTP Component.
Jetty is stream based, which means the input it receives is submitted to Camel as a
stream. That means you will only be able to read the content of the stream
once. If you find a situation where the message body appears to be
empty or you need to access the data multiple times (eg: doing multicasting, or redelivery
error handling) you should use Stream Caching or convert the message
body to a String which is safe to be re-read multiple times.
The URI format for a Jetty endpoint is:
jetty:http(s)://hostname[:port][/resourceUri][?options]
Table 5.6 lists the options for a Jetty endpoint.
Table 5.6. Jetty options
| Name | Default | Description |
|---|---|---|
sessionSupport | false | Specifies whether to enable the session manager on the server side of Jetty. |
httpClient. | Specifies options to set on Jetty's
HttpClient. For example, setting httpClient.idleTimeout=30000
sets the idle timeout to 30 seconds. | |
httpBindingRef | Specifies a reference to an
org.apache.camel.component.http.HttpBinding in the registry. | |
jettyHttpBindingRef | Specifies a reference to an
org.apache.camel.component.jetty.JettyHttpBinding in the
registry. | |
matchOnUriPrefix | false | Specifies whether or not the CamelServlet should try to find a
target consumer by matching the URI prefix if no exact match is found. |
handlers | Specifies a comma-delimited set of
org.mortbay.jetty.Handler instances in the registry that are added to
the Jetty servlet context. | |
chunked | true | Specifies if the Jetty servlet uses HTTP streaming. |
enableJmx | false | Specifies if Jetty JMX support will be enabled for this endpoint. |
disableStreamCache | false | Specifies if the raw input stream from Jetty is cached or not. |
bridgeEndpoint | false |
Specifies if the HttpProducer and CamelServlet will skip the gzip processing
when the content-encoding is |
enableMultipartFilter | true | Specifies if Jetty org.eclipse.jetty.servlets.MultiPartFilter
is enabled. You should set this value to false when bridging
endpoints, to ensure multipart requests are proxied/bridged as well. |
multipartFilterRef | Specifies a reference to a custom multipart filter.
Setting multipartFilterRef forces the value of
enableMultipartFilter to true. | |
continuationTimeout | 30000 | Specifies a timeout, in milliseconds, when using Jetty as consumer. Zero or a negative value means the endpoint will never timeout. This option is only used when using Jetty with the asynchronous routing engine. |
useContinuation | true | Specifies whether or not to use Jetty continuations for the Jetty server. |
Apache Camel uses the same message headers as the HTTP component. It also uses the
CamelHttpChunked header to turn on or turn off the chuncked encoding on the
consumer.
Apache Camel also populates all request.parameter
and request.headers. For example, given a client request with the URL
http://myserver/myserver?orderid=123, the exchange will contain a header
named orderid with the value 123.
The JettyHttpComponent provides the following options:
| Name | Default | Description |
|---|---|---|
enableJmx
| false
| If this option is true, Jetty JMX support will be enabled for this endpoint. |
sslKeyPassword
| null
| Consumer only: Specifies the password for the keystore when using SSL. |
sslPassword
| null
| Consumer only: Specifies the password when using SSL. |
sslKeystore
| null
| Consumer only: Specifies the path to the keystore. |
minThreads
| Consumer only: Specifies the minimum number of threads in server thread pool. | |
maxThreads | Consumer only: Specifies the maximum number of threads in server thread pool. | |
threadPool
| null
| Consumer only: Specifies a custom thread pool for the server. |
sslSocketConnectors | Consumer only: Specifies a map containing per port number specific SSL connectors. | |
socketConnectors | Consumer only:Specifies a map containing per port number specific HTTP connectors. | |
sslSocketConnectorProperties
| null
| Consumer only: Specifies a map containing general SSL connector properties. |
socketConnectorProperties
| null
| Consumer only: Specifies a map containing general HTTP connector properties. |
httpClient | Producer only: Specifies a custom
HttpClient to use with the Jetty producer. | |
httpClientMinThreads | Producer only: Specifies the minimum number of
threads in HttpClient thread pool. | |
httpClientMaxThreads | Producer only: Specifies the maximum number of
threads in HttpClient thread pool. | |
httpClientThreadPool | Producer only:Specifies a custom thread pool for the client. |
Restlet — provides Restlet-based endpoints for consuming and producing RESTful resources
The URI format for a Restlet endpoint is:
restlet:http://hostname[:port][/resourcePattern][?options]
The default port is port 80.
Table 5.7 lists the options for a Servlet endpoint.
Table 5.7. Restlet endpoint options
| Name | Default | Description |
|---|---|---|
headerFilterStrategy | Specifies the bean ID of a header filter strategy in the registry. The strategy
will be plugged into the restlet binding if it is
HeaderFilterStrategyAware. | |
restletBinding | Specifies the bean ID of a RestletBinding object in the
registry. | |
restletMethod | GET | On a producer endpoint, specifies the request method to use. On a consumer
endpoint, specifies that the endpoint consumes only
restletMethod requests. |
restletMethods | Consumer only: Specifies one or more methods
separated by commas to be serviced by a restlet consumer endpoint.
restletMethods takes president over
restletMethod. | |
restletUriPatterns | Consumer only: Specifies one ore more URI
templates to be serviced by a restlet consumer endpoint using the
# notation to reference a List<String> in the
registry. If a URI pattern has been defined in the endpoint URI, both the URI pattern
defined in the endpoint and the restletUriPatterns option will be
honored. |
Restlet endpoints use the following message headers:
| Name | Type | Description |
|---|---|---|
Content-Type | String | Specifies the content type of the response message. If this header is not set,
the content type is based on the object type of the OUT message body. If the content
type is specified in the IN message, that value determines the content type for the
Restlet request message. Otherwise, the content type is defaulted to
application/x-www-form-urlencoded. |
CamelHttpMethod | String | Specifies the HTTP request method. This is set in the IN message header. |
CamelHttpQuery | String | Specifies the query string of the request URI. It is set on the IN message the endpoint receives a request. |
CamelHttpResponseCode | String or Integer | Specifies the response code to set on the OUT message by the application/processor. The value is the response code of the response message. If this header is not set, the response code is set by the restlet runtime engine. |
CamelHttpUri | String | Specifies the HTTP request URI. This is set in the IN message header. |
CamelRestletLogin | String | Specifies the login name for basic authentication. It is set on the IN message by the application and gets filtered before the restlet request header. |
CamelRestletPassword | String | Specifies the password for basic authentication. It is set on the IN message by the application and gets filtered before the restlet request header. |
org.restlet.* | Specifies the attributes of a Restlet message that get propagated to Apache Camel IN headers. |
Servlet — provides support for HTTP endpoints that are published as servlets
You can only consume from endpoints generated by the Servlet component. Therefore, it should only be used as input into your Apache Camel routes. To issue HTTP requests against other HTTP endpoints, use the HTTP Component.
Maven users will need to add the following dependency to their
pom.xml for this component:
Example 5.1. Adding the servlet dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-servlet</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 5.8 lists the options for a Servlet endpoint.
Table 5.8. Servlet endpoint options
| Name | Default | Description |
|---|---|---|
httpBindingRef | Specifies a reference to an
org.apache.camel.component.http.HttpBinding in the registry. | |
matchOnUriPrefix | false | Specifies if the CamelServlet should try to find a target
consumer by matching the URI prefix if no exact match is found. |
servletName | Specifies the servlet name that the endpoint will bind to. If there is no servlet name specified, the endpoint will be bind to first published Servlet. |
Apache Camel will apply the same Message Headers as the HTTP component.
Apache Camel will also populate all request.parameter and
request.headers. For example, if a client request has the URL,
http://myserver/myserver?orderid=123, the exchange will contain a
header named orderid with the value 123.
Seda — provides an asynchronous connection to any consumer in the
same camelContext element
Seda endpoints provide asynchronous SEDA behavior, so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread from the producer.
Queues are only visible within a single
camelContext element. If you want to communicate across
camelContext elements, use a
vm endpoint.
| Synchronous |
|---|---|
Direct endpoints provide synchronous invocation of any consumers when a producer sends a message exchange. |
Example 6.1 shows the syntax for a Seda endpoint URI.
queueName can be any string that uniquely identifies the
endpoint within the current camelContext elements.
| Note |
|---|---|
When matching consumer endpoints to producer endpoints, only the
|
Table 6.1 describes the Seda component's options.
Table 6.1. Seda component options
| Name | Default | Description |
|---|---|---|
size | Unbounded | Specifies the maximum size of the SEDA queue. |
concurrentConsumers | 1 | Specifies the number of concurrent threads processing exchanges. |
waitForTaskToComplete | IfReplyExpected | Specify whether the caller should wait for the task to complete before continuing.
Valid settings are Always, Never or
IfReplyExpected. IfReplyExpected specifies that
the caller will only wait if the message exchange pattern is request/reply. |
timeout | 30000 | Specifies the maximum amount of time, in milliseconds, that a producer will wait for a task to complete before timing out. |
multipleConsumers | false | Specifies whether multiple consumers are allowed or not. If enabled, multiple consumers can receive messages from a SEDA queue. |
limitConcurrentConsumers | true | Specifies whether to limit the number of concurrent consumers to a maximum of
500. If true setting concurrentConsumers to a
number greater than 500 causes an exception to be thrown. |
VM — provides an asynchronous connection to consumers in other
camelContext elements
VM endpoints provide asynchronous SEDA behavior so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread pool to the producer.
VM endpoints differ from Seda endpoints in that VM endpoints support communication across CamelContext instances.
ActiveMQ — allows messages to be sent to or consumed from a JMS destination using Fuse MQ Enterprise
The ActiveMQ component is a specialized version of the
JMS component that makes connecting to Fuse MQ Enterprise easy.
It uses Spring's JMS support for declarative transactions, using Spring's
JmsTemplate for sending and a
MessageListenerContainer for consuming.
The URI format for an ActiveMQ endpoint is:
activemq:[queue:|topic:]destinationName?options
Where destinationName is an Fuse MQ Enterprise queue or topic name. By
default, destinationName is interpreted as a queue name. To
connect to a topic, you must include the topic: prefix.
To use this component make sure the following are on the application's classpath:
activemq.jar or activemq-core.jar
camel-core.jar
camel-spring.jar
camel-jms.jar
In addition, camel-jms and activemq-camel must be
listed as a dependency in the pom as shown in Example 7.1.
Example 7.1. Fuse MQ Enterprise dependencies
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-jms</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>org.apache.activemq</groupId> <artifactId>activemq-camel</artifactId> <version>5.2.0</version> </dependency>
AMQP — supports the AMQP protocol
Maven users will need to add the dependency shown in Example 7.2 to their
pom.xml to use this component.
Example 7.2. AMQP dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-ampq</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>The AMQP component uses the same set of options as the JMS component. For more information see the JMS component options.
IRC — sends and receives messages using the IRC protocol
The IRC component supports two URI formats:
irc:nick@host[:port]/#room[?options]
irc:nick@host[:port]?channels=#channel1,#channel2,#channel3[?options]
You can append query options to the URI in the following format:
?option=value&option=value&...
To use SSL the format changes to:
ircs:host[:port]/#room?username=user&password=pass&trustManager=#referenceToMyTrustManagerBean
Table 7.1 lists the options for an IRC endpoint.
Table 7.1. IRC options
| Name | Description | Default Value |
|---|---|---|
channels | Specifies a comma separated list of IRC channels to join. | null |
nickname | Specifies the nickname used in chat. | null
|
username | Specifies the user name to log into the IRC server. | Same as nickname |
password | Specifies the password to log into the IRC server. | |
realname | Specifies the IRC user's actual name. | |
colors | Specifies whether or not the server supports color codes. | true |
onReply
| Whether or not to handle general responses to commands or informational messages. | false
|
onNick
| Handle nickname change events. | true
|
onQuit
| Handle user quit events. | true
|
onJoin
| Handle user join events. | true
|
onKick
| Handle kick events. | true
|
onMode
| Handle mode change events. | true
|
onPart
| Handle user part events. | true
|
onTopic
| Handle topic change events. | true
|
onPrivmsg
| Handle message events. | true
|
trustManager
| Specifies the trust manager used to verify the SSL server's certificate. | The default trust manager, which accepts all certificates, will be used. |
keys
| Specifies a comma separated list of IRC channel keys. The keys must be listed in same order as channels. When joining multiple channels with only some needing keys insert an empty value for any channel that does not require a key. | null
|
JMS — allows message to be sent to or consumed from JMS destinations
The JMS component allows messages to be sent to (or consumed from) a
JMS destination. 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.
| Using ActiveMQ |
|---|---|
If you are using Fuse MQ Enterprise, you should use the ActiveMQ endpoint. It has been optimized for Fuse MQ Enterprise. |
Table 7.2 lists the options for a JMS endpoint.
| Note |
|---|---|
Many of these properties map to properties on Spring JMS, which Apache Camel uses for sending and receiving messages. You can get more information about these properties by consulting the relevant Spring documentation. |
Table 7.2. JMS options
| Option | Default | Description |
|---|---|---|
acceptMessagesWhileStopping | false | Specifies whether the consumer accept messages while it is stopping. |
acknowledgementModeName | AUTO_ACKNOWLEDGE |
Specifies the JMS acknowledgement mode. Valid values are:
|
acknowledgementMode | -1 | Specifies the JMS acknowledgement mode defined as an integer. Allows you to set
vendor-specific extensions to the acknowledgment mode. For the regular modes, it is
preferable to use the acknowledgementModeName instead. |
alwaysCopyMessage | false | Specifies if Apache Camel will make a JMS message copy of the message when it is passed to the producer for sending. |
autoStartup | true | Specifies whether the consumer container should auto-startup. |
cacheLevelName | CACHE_CONSUMER | Specifies the cache level by name for the underlying JMS resources. Possible values are:
|
cacheLevel | -1 | Specifies the cache level by ID for the underlying JMS resources. |
clientId | null | Specifies the JMS client ID to use. This value, if specified, must be unique and can only be used by a single JMS connection instance. It is typically only required for durable topic subscriptions. |
consumerType | Default |
Specifies the consumer type to use. Valid values are one of:
The consumer type determines which Spring JMS listener to use. |
concurrentConsumers
| 1
| Specifies the default number of concurrent consumers. |
connectionFactory
| null
| Specifies the default JMS connection factory to use for the
listenerConnectionFactory and
templateConnectionFactory, if neither is specified. |
deliveryMode
| 2
| Specifies the delivery mode when sending messages. 1 =
non-persistent; 2 = persistent. |
deliveryPersistent
| true
| Specifies whether persistent delivery is used by default. |
destination
| null
| Specifies the JMS Destination object to use on this endpoint. |
destinationName
| null
| Specifies the JMS destination name to use on this endpoint. |
destinationResolver
| null
| Specifies an implementation of the Spring framework's
DestinationResolver to use. |
disableReplyTo
| false
| Specifies whether to ignore the JMSReplyTo header and treat
messages as InOnly by default. |
durableSubscriptionName
| null
| Specifies the durable subscriber name for specifying durable topic subscriptions. The
clientId option must be configured
as well. |
eagerLoadingOfProperties
| false
| Enables eager loading of JMS properties as soon as a message is received. |
exceptionListener
| null
| Specifies the JMS Exception Listener that is to be notified of any underlying JMS exceptions. |
explicitQosEnabled | false | Specifies whether the deliveryMode, priority or
timeToLive qualities of service should be used when sending
messages. |
exposeListenerSession
| true
| Specifies whether the listener session should be exposed when consuming messages. |
idleTaskExecutionLimit
| 1
| Specifies 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. |
jmsMessageType
| null
|
Forces the use of a specific
|
jmsKeyFormatStrategy
| default
|
Specifies a pluggable strategy for encoding and decoding JMS keys so they can be compliant with the JMS specification. Apache Camel provides two implementations out of the box:
|
jmsOperations
| null
| Specifies an implementation of the Spring Framework's
JmsOperations interface to use in place
of JmsTemplate. |
lazyCreateTransactionManager
| true
| Specifies if Apache Camel will
create a JmsTransactionManager when no
transactionManager injected when
transacted=true. |
listenerConnectionFactory
| null
| Specifies the JMS connection factory used for consuming messages. |
mapJmsMessage | true | Specifies whether Apache Camel should
auto map the received JMS message to an appropriate payload type, such as
javax.jms.TextMessage to a String etc. |
maxConcurrentConsumers | 1 | Specifies the maximum number of concurrent consumers. |
maxMessagesPerTask | -1 (unlimited) | Specifies the maximum number of messages per task. |
messageConverter | null | Specifies a custom implementation of the Spring
MessageConverter so you can control how to map
to/from a javax.jms.Message. |
messageIdEnabled
| true
| Specifies whether message IDs should be added to outgoing messages. |
messageTimestampEnabled | true | Specifies whether timestamps should be enabled by default on sending messages. |
password
| null
| Specifies the password for the connector factory. |
priority
| 4
| Specifies the priority of outgoing messages. The
explicitQosEnabled option
must also be enabled in order
for this option to have any effect. |
pubSubNoLocal
| false
| Specifies whether to inhibit the delivery of messages published by its own connection. |
receiveTimeout | Specifies the timeout for receiving messages (in milliseconds). | |
recoveryInterval
| 5000
| Specifies the interval between recovery attempts, in milliseconds. |
preserveMessageQos
| false
| Specifies if you want to send message using the QoS settings specified on the
message instead of the QoS settings on the JMS endpoint. The following three headers
are considered: JMSPriority, JMSDeliveryMode, and
JMSExpiration. |
replyTo
| null
| Specifies an explicit ReployTo destination, which overrides any incoming value of
Message.getJMSReplyTo(). |
replyToDestinationSelectorName
| null
| Specifies the JMS Selector using the fixed name to be used so you can filter out your own replies from the others when using a shared queue (that is, if you are not using a temporary reply queue). |
replyToDeliveryPersistent
| true
| Specifies whether to use persistent delivery by default for replies. |
requestTimeout
| 20000
| Specifies the timeout for waiting for a reply when using the InOut Exchange Pattern in milliseconds. |
selector
| null
| Specifies the JMS Selector, which is an SQL 92 predicate that is used to filter messages within the broker. |
taskExecutor
| null
| Specifies a custom task executor for consuming messages. |
taskExecutorSpring2
| null
| Specifies a custom task executor for consuming messages when using Spring 2.x. |
templateConnectionFactory
| null
| Specifies the JMS connection factory used for sending messages. |
timeToLive
| null
| Specifies the time-to-live of the message in milliseconds. The
explicitQosEnabled option must also
be enabled in order for this option to have any effect. |
transacted
| false
| Specifies whether to use transacted mode for sending/receiving messages using the InOnly Exchange Pattern. |
transactionManager
| null
| Specifies the Spring transaction manager to use. |
transactionName
| null
| Specifies the name of the transaction to use. |
transactionTimeout
| null
| Specifies the timeout value of the transaction. |
transferException
| false
| Specifies if enabled an exception thrown by a client during processing is returned as the response message. |
transferExchange
| false
| Specifies if the exchange is transmitted over the wire instead of just the body and headers. The following fields are transferred: In body, Out body, Fault body, In headers, Out headers, Fault headers, exchange properties, exchange exception. |
username
| null
| Specifies the username for the connector factory. |
useMessageIDAsCorrelationID
| false
| Specifies whether JMSMessageID should always be used as
JMSCorrelationID for InOut messages. |
Apache Camel automatically maps messages between javax.jms.Message and
org.apache.camel.Message.
When sending a JMS message, Apache Camel converts the message body to the JMS message types shown in Table 7.3 .
Table 7.3. Mapping from Apache Camel to JMS
| Body Type | JMS Message |
|---|---|
String | javax.jms.TextMessage |
org.w3c.dom.Node
| javax.jms.TextMessage |
Map
| javax.jms.MapMessage
|
java.io.Serializable
| javax.jms.ObjectMessage
|
byte[] | javax.jms.BytesMessage |
java.io.File
| javax.jms.BytesMessage
|
java.io.Reader
| javax.jms.BytesMessage
|
java.io.InputStream
| javax.jms.BytesMessage
|
java.nio.ByteBuffer
| javax.jms.BytesMessage
|
When receiving a JMS message, Apache Camel converts the JMS message to body type listed in Table 7.4.
Table 7.4. Mapping from JMS to Apache Camel
| JMS Message | Body Type |
|---|---|
javax.jms.TextMessage | String |
javax.jms.BytesMessage | byte[] |
javax.jms.MapMessage | Map<String, Object> |
javax.jms.ObjectMessage | Object |
Mail — provides access to e-mail systems
The Mail component provides access to Email via Spring's Mail support and the underlying JavaMail system.
![[Warning]](imagesdb/warning.gif) | Geronimo mail JAR |
|---|---|
The Geronimo mail JAR (v1.6) has a bug when polling e-mails with attachments. It
cannot correctly identify the You can set your custom resolver on the |
| POP3 or IMAP |
|---|---|
POP3 has some limitations and end users are encouraged to use IMAP if possible. |
| Using mock-mail for testing |
|---|---|
You can use a mock framework for unit testing, which allows you to test without the need
for a real mail server. However you should remember to not include mock-mail when you go
into production or other environments where you need to send mails to a real mail server.
Just the presence of the |
Mail endpoints can have one of the URI formats listed in Table 7.5.
Table 7.5. Mail URI Formats
| Mail Protocol | URI Format |
|---|---|
| SMTP | smtp(s)://[ |
| POP3 | pop3(s)://[ |
| IMAP | imap(s)://[ |
Mail endpoints also supports secure variants of these protocols that are layered over
SSL. You can enable the secure protocols by adding s to the scheme.
Table 7.6 lists the default port numbers that are used if the port number is omitted.
Table 7.6. Default mail port numbers
| Protocol | Default Port Number |
|---|---|
| SMTP | 25 |
| SMTPS | 465 |
| POP3 | 110 |
| POP3S | 995 |
| IMAP | 143 |
| IMAPS | 993 |
Table 7.7 describes the options for Mail endpoints.
Table 7.7. Mail endpoint options
| Property | Default | Description |
|---|---|---|
host
| The host name or IP address to connect to. | |
port
| See Table 7.6 | The TCP port number to connect on. |
username | The user name on the email server. | |
password
| The password on the email server. | |
ignoreUriScheme
| false
| If false, Apache Camel uses the scheme to determine the transport
protocol (POP, IMAP, SMTP etc.) |
defaultEncoding
| The default encoding to use for Mime Messages. | |
contentType
| text/plain
| The mail message content type. Use text/html for HTML mails. |
folderName
| INBOX
| The folder to poll. |
to
| | The recipients. Separate multiple email addresses with a comma. |
CC
| The CC recipients. Separate multiple email addresses with a comma. | |
BCC | The BCC recipients. Separate multiple email addresses with a comma. | |
from
| camel@localhost
| The FROM email address. |
subject
| The Subject of the message being sent. Note: Setting the subject in the header takes precedence over this option. | |
delete
| false
| Deletes the messages after they have been
processed. This is done by setting the DELETED flag on the mail
message. If false, the SEEN flag is set instead.
|
unseen
| true
| Is used to only fetch unseen(new) messages. POP3 does not support the
SEEN flag. |
fetchSize
| -1
| Specifies the maximum number of messages to consume during a poll.The default value
of -1 means all available messages will be consumed. Setting the
value to 0 means Apache Camel will not consume any messages. |
alternativeBodyHeader
| CamelMailAlternativeBody
| Specifies the key to an IN message header
that contains an alternative email body. For example, if you send emails in
text/html format and want to provide an alternative mail body for
non-HTML email clients, set the alternative mail body with this key as a header. |
debugMode
| false
| Specifies if debug mode is enabled on the underlying mail framework. The SUN Mail
framework logs the debug messages to System.out by default. |
connectionTimeout
| 30000
| The connection timeout can be configured in milliseconds. |
consumer.initialDelay
| 1000
| Milliseconds before the polling starts. |
consumer.delay
| 60000
| Specifies the consumer delay in milliseconds. |
consumer.useFixedDelay
| false
| Set to true to use a fixed delay between polls, otherwise fixed rate
is used. See ScheduledExecutorService in JDK for details. |
mail.
| You can set any additional java mail properties. | |
maxMessagesPerPoll
| 0
| Specifies the maximum number of messages to gather per poll. The default value of
0 (or a negative value) disables this option. |
javaMailSender
| Specifies a custom implementation of the Spring
JavaMailSender interface in order to use a custom email
implementation. If none provided, Apache Camel uses the default Spring
JavaMailSenderImpl implementation. | |
ignoreUnsupportedCharset
| false
| Option to let Apache Camel ignore unsupported
charsets in the local JVM when sending mails. If the charset is unsupported then
charset=XXX is removed from the
content-type and it relies on the platform default instead. |
The underlying mail framework is responsible for providing SSL support. Apache Camel uses SUN
JavaMail, which only trusts certificates issued by well known Certificate Authorities. So if
you issue your own certificate, you have to import it into the local Java keystore file (see
SSLNOTES.txt in JavaMail for details).
SUN JavaMail is used under the hood for consuming and producing mails. We encourage end-users to consult these references when using either POP3 or IMAP protocol. Note particularly that POP3 has a much more limited set of features than IMAP.
And generally about the MAIL Flags
MSMQ — works with Microsoft Message Queuing
The MSMQ component is a transport for working with Microsoft Message Queuing This component natively sends and receives directly
allocated ByteBuffer instances. This allows you to access the JNI layer
without expensive memory copying. In fact, if a ByteBuffer is created by
the allocateDirect method, it can be passed to the JNI layer and the native
code is able to access the memory directly. It's up to the developer to marshal/unmarshal any
other kinds of payload to/from directly allocated ByteBuffer instances.
Look at the tests to see some usage examples.
Table 7.8 lists the options for an MSMQ endpoint.
Table 7.8. MSMQ options
| Name | Default Value | Description |
|---|---|---|
deliveryPersistent
| false
| If true, the message is put persistently on the queue. |
priority
| 5
| The message priority, lying in the range 1-7 |
timeToLive
| INFINITE
| The maximum amount of time (specified in seconds) that a message can spend travelling to its destination. If this limit is exceeded, the message is discarded. |
concurrentConsumers
| 1
| The numbers of consumers that get messages from the queue at the same time. |
initialBufferSize
| 128
| The initial buffer size |
incrementBufferSize
| 128
| Specifies the number of bytes to increase the buffer if it is not large enough. |
SIP — supports the SIP Publish and Subscribe capability as described in the [RFC3903 - Session Initiation Protocol (SIP) Extension for Event]
The SIP component in Apache Camel is a communication component, based on the Jain SIP implementation (available under the JCP license).
Session Initiation Protocol (SIP) is an IETF-defined signaling protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP).The SIP protocol is an Application Layer protocol designed to be independent of the underlying transport layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP).
The Jain SIP implementation supports TCP and UDP only.
The Apache Camel SIP component only supports the SIP Publish and Subscribe capability as described in the RFC3903 - Session Initiation Protocol (SIP) Extension for Event
This component supports both producer and consumer endpoints.
Apache Camel SIP Producers (Event Publishers) and SIP Consumers (Event Subscribers) communicate event & state information to each other using an intermediary entity called a SIP Presence Agent (a stateful brokering entity).
The URI scheme for a SIP endpoint is as follows:
sip://username@host:port[?options] sips://username@host:port[?options]
For SIP based communication, a SIP Stack with a listener must be instantiated on both the SIP Producer and Consumer (using separate ports if using localhost). This is necessary in order to support the handshakes & acknowledgements exchanged between the SIP Stacks during communication.
Maven users will need to add the dependency shown in Example 7.3 to their
pom.xml to use this component.
Example 7.3. SIP dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-sip</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Table 7.9 lists the options for a SIP endpoint.
Table 7.9. SIP Options
| Name | Default Value | Description |
|---|---|---|
stackName
| NAME_NOT_SET
| Name of the SIP Stack instance associated with an SIP Endpoint. |
transport
| tcp
| Setting for choice of transport potocol. Valid choices are "tcp" or "udp". |
fromUser
| Username of the message originator. Mandatory setting unless a registry based custom FromHeader is specified. | |
fromHost
| Hostname of the message originator. Mandatory setting unless a registry based FromHeader is specified | |
fromPort
| Port of the message originator. Mandatory setting unless a registry based FromHeader is specified | |
toUser
| Username of the message receiver. Mandatory setting unless a registry based custom ToHeader is specified. | |
toHost
| Hostname of the message receiver. Mandatory setting unless a registry based ToHeader is specified | |
toPort
| Portname of the message receiver. Mandatory setting unless a registry based ToHeader is specified | |
maxforwards
| 0 | the number of intermediaries that may forward the message to the message receiver. Optional setting. May alternatively be set using as registry based MaxForwardsHeader |
eventId
| Setting for a String based event Id. Mandatory setting unless a registry based FromHeader is specified | |
eventHeaderName
| Setting for a String based event Id. Mandatory setting unless a registry based FromHeader is specified | |
maxMessageSize
| 1048576
| Setting for maximum allowed Message size in bytes. |
cacheConnections
| false
| Should connections be cached by the SipStack to reduce cost of connection creation. This is useful if the connection is used for long running conversations. |
consumer
| false
| This setting is used to determine whether the kind of header (FromHeader,ToHeader etc) that needs to be created for this endpoint |
automaticDialogSupport
| off
| Setting to specify whether every communication should be associated with a dialog. |
contentType
| text
| Setting for contentType can be set to any valid MimeType. |
contentSubType
| xml
| Setting for contentSubType can be set to any valid MimeSubType. |
receiveTimeoutMillis
| 10000
| Setting for specifying amount of time to wait for a Response and/or Acknowledgement can be received from another SIP stack |
useRouterForAllUris
| false
| This setting is used when requests are sent to the Presence Agent via a proxy. |
msgExpiration
| 3600
| The amount of time a message received at an endpoint is considered valid |
presenceAgent
| false
| This setting is used to distingish between a Presence Agent & a consumer. This is due to the fact that the SIP Camel component ships with a basic Presence Agent (for testing purposes only). Consumers have to set this flag to true. |
SIP requires a number of headers to be sent/received as part of a request. These SIP header can be enlisted in the Registry, such as in the Spring XML file.
Table 7.10 describes the values.
Table 7.10. SIP registry based options
| Name | Description |
|---|---|
fromHeader
| a custom Header object containing message originator settings. Must implement the type javax.sip.header.FromHeader |
toHeader
| a custom Header object containing message receiver settings. Must implement the type javax.sip.header.ToHeader |
viaHeaders
| List of custom Header objects of the type javax.sip.header.ViaHeader. Each ViaHeader containing a proxy address for request forwarding. (Note this header is automatically updated by each proxy when the request arrives at its listener) |
contentTypeHeader
| a custom Header object containing message content details. Must implement the type javax.sip.header.ContentTypeHeader |
callIdHeader
| a custom Header object containing call details. Must implement the type javax.sip.header.CallIdHeader |
maxForwardsHeader
| a custom Header object containing details on maximum proxy forwards. This header places a limit on the viaHeaders possible. Must implement the type javax.sip.header.MaxForwardsHeader |
eventHeader
| a custom Header object containing event details. Must implement the type javax.sip.header.EventHeader |
contactHeader
| an optional custom Header object containing verbose contact details (email, phone number etc). Must implement the type javax.sip.header.ContactHeader |
expiresHeader
| a custom Header object containing message expiration details. Must implement the type javax.sip.header.ExpiresHeader |
extensionHeader
| a custom Header object containing user/application specific details. Must implement the type javax.sip.header.ExtensionHeader |
SMPP — provides access to an SMSC (Short Message Service Center) over the SMPP protocol
This component provides access to an SMSC (Short Message Service Center) over the SMPP protocol to send and receive SMS. The JSMPP library is used to implement the connections.
The URI scheme for an SMPP endpoint is as follows:
smpp://[username@]hostname[:port][?options] smpps://[username@]hostname[:port][?options]
If no username is provided, Apache Camel will provide the default value
smppclient.
If no port number is provided, Apache Camel will
provide the default value 2775.
If the protocol name is smpps, Apache Camel will try to use SSLSocket to
initialize a connection to the server.
Table 7.11 lists the options for a SMPP endpoint.
Table 7.11. SMPP Options
| Name | Default Value | Description |
|---|---|---|
password
| password
| Specifies the password to use to log in to the SMSC. |
systemType
| cp
| This parameter is used to categorize the type of ESME (External Short Message Entity) that is binding to the SMSC (max. 13 characters). |
dataCoding
| 0
|
Defines encoding of data according the SMPP 3.4 specification, section 5.2.19. Example data encodings are:
|
encoding
| ISO-8859-1
| Defines the encoding scheme of the short message user data. |
enquireLinkTimer
| 5000
| Defines the interval in milliseconds between the confidence checks. The confidence check is used to test the communication path between an ESME and an SMSC. |
transactionTimer
| 10000
| Defines the maximum period of inactivity allowed after a transaction, after which an SMPP entity may assume that the session is no longer active. This timer may be active on either communicating SMPP entity (i.e. SMSC or ESME). |
initialReconnectDelay
| 5000
| Defines the initial delay in milliseconds after the consumer/producer tries to reconnect to the SMSC, after the connection was lost. |
reconnectDelay
| 5000
| Defines the interval in milliseconds between the reconnect attempts, if the connection to the SMSC was lost and the previous was not succeed. |
registeredDelivery
| 1
|
Is used to request an SMSC delivery receipt and/or SME originated acknowledgements.
The following values are defined: |
serviceType
| CMT
|
The service type parameter can be used to indicate the SMS Application service associated with the message. The following generic service_types are defined:
|
sourceAddr
| 1616
| Defines the address of SME (Short Message Entity) which originated this message. |
destAddr
| 1717
| Defines the destination SME address. For mobile terminated messages, this is the directory number of the recipient MS. |
sourceAddrTon
| 0
|
Defines the type of number (TON) to be used in the SME originator address parameters. The following TON values are defined:
|
destAddrTon
| 0
|
Defines the type of number (TON) to be used in the SME destination address parameters. The following TON values are defined:
|
sourceAddrNpi
| 0
|
Defines the numeric plan indicator (NPI) to be used in the SME originator address parameters. The following NPI values are defined:
|
destAddrNpi
| 0
|
Defines the numeric plan indicator (NPI) to be used in the SME destination address parameters. The following NPI values are defined:
|
priorityFlag
| 1
|
Allows the originating SME to assign a priority level to the short message. Four Priority Levels are supported:
|
replaceIfPresentFlag
| 0
|
Used to request the SMSC to replace a previously submitted message, that is still pending delivery. The SMSC will replace an existing message provided that the source address, destination address and service type match the same fields in the new message. The following replace if present flag values are defined:
|
dataCoding
| 0
|
Defines encoding of data according the SMPP 3.4 specification, section 5.2.19. Example data encodings are:
|
typeOfNumber
| 0
|
Defines the type of number (TON) to be used in the SME. The following TON values are defined:
|
numberingPlanIndicator
| 0
|
Defines the numeric plan indicator (NPI) to be used in the SME. The following NPI values are defined:
|
Table 7.12 describes the message headers that affect the behavior of the SMPP producer.
Table 7.12. SMPP producer headers
| Header | Description |
|---|---|
CamelSmppDestAddr
| Defines the destination SME address. For mobile terminated messages, this is the directory number of the recipient MS. |
CamelSmppDestAddrTon
|
Defines the type of number (TON) to be used in the SME destination address parameters. The following TON values are defined:
|
CamelSmppDestAddrNpi
|
Defines the numeric plan indicator (NPI) to be used in the SME destination address parameters. The following NPI values are defined:
|
CamelSmppSourceAddr
| Defines the address of SME (Short Message Entity) which originated this message. |
CamelSmppSourceAddrTon
|
Defines the type of number (TON) to be used in the SME originator address parameters. The following TON values are defined:
|
CamelSmppSourceAddrNpi
|
Defines the numeric plan indicator (NPI) to be used in the SME originator address parameters. The following NPI values are defined:
|
CamelSmppServiceType
|
The service type parameter can be used to indicate the SMS Application service associated with the message. The following generic service_types are defined:
|
CamelSmppRegisteredDelivery
|
Is used to request an SMSC delivery receipt and/or SME originated acknowledgements. The following values are defined:
|
CamelSmppPriorityFlag
|
Allows the originating SME to assign a priority level to the short message. Four Priority Levels are supported:
|
CamelSmppScheduleDeliveryTime
| This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC. It can be specified in either absolute time format or relative time format. The encoding of a time format is specified in chapter 7.1.1. in the smpp specification v3.4. |
CamelSmppValidityPeriod
| The validity period parameter indicates the SMSC expiration time, after which the message should be discarded if not delivered to the destination. It can be defined in absolute time format or relative time format. The encoding of absolute and relative time format is specified in chapter 7.1.1 in the smpp specification v3.4. |
CamelSmppReplaceIfPresentFlag
|
The replace if present flag parameter is used to request the SMSC to replace a previously submitted message, that is still pending delivery. The SMSC will replace an existing message provided that the source address, destination address and service type match the same fields in the new message. The following values are defined:
|
CamelSmppDataCoding
|
The data coding according to the SMPP 3.4 specification, section 5.2.19:
|
The following message headers are used by the SMPP producer to set the response from the SMSC in the message header
Table 7.13. SMPP headers for the SMSC
| Header | Description |
|---|---|
CamelSmppId
| the id to identify the submitted short message for later use (delivery receipt, query sm, cancel sm, replace sm). |
The following message headers are used by the SMPP consumer to set the request data from the SMSC in the message header.
Table 7.14. SMMP consumer headers
| Header | Description |
|---|---|
CamelSmppSequenceNumber
| only for alert notification, deliver sm and data sm: A sequence number allows a response PDU to be correlated with a request PDU. The associated SMPP response PDU must preserve this field. |
CamelSmppCommandId
| only for alert notification, deliver sm and data sm: The command id field identifies the particular SMPP PDU. For the complete list of defined values see chapter 5.1.2.1 in the smpp specification v3.4. |
CamelSmppSourceAddr
| only for alert notification, deliver sm and data sm: Defines the address of SME (Short Message Entity) which originated this message. |
CamelSmppSourceAddrNpi
|
only for alert notification and data sm: Defines the numeric plan indicator (NPI) to be used in the SME originator address parameters. The following NPI values are defined:
|
CamelSmppSourceAddrTon
|
only for alert notification and data sm: Defines the type of number (TON) to be used in the SME originator address parameters. The following TON values are defined:
|
CamelSmppEsmeAddr
| only for alert notification: Defines the destination ESME address. For mobile terminated messages, this is the directory number of the recipient MS. |
CamelSmppEsmeAddrNpi
|
only for alert notification: Defines the numeric plan indicator (NPI) to be used in the ESME originator address parameters. The following NPI values are defined:
|
CamelSmppEsmeAddrTon
|
only for alert notification: Defines the type of number (TON) to be used in the ESME originator address parameters. The following TON values are defined:
|
CamelSmppId
| only for smsc delivery receipt and data sm: The message ID allocated to the message by the SMSC when originally submitted. |
CamelSmppDelivered
| only for smsc delivery receipt: Number of short messages delivered. This is only relevant where the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. |
CamelSmppDoneDate
| only for smsc delivery receipt: The time and date at which the short message reached it's final state. The format is as follows: YYMMDDhhmm. |
CamelSmppStatus
|
only for smsc delivery receipt and data sm: The final status of the message. The following values are defined:
|
CamelSmppError
| only for smsc delivery receipt: Where appropriate this may hold a Network specific error code or an SMSC error code for the attempted delivery of the message. These errors are Network or SMSC specific and are not included here. |
CamelSmppSubmitDate
| only for smsc delivery receipt: The time and date at which the short message was submitted. In the case of a message which has been replaced, this is the date that the original message was replaced. The format is as follows: YYMMDDhhmm. |
CamelSmppSubmitted
| only for smsc delivery receipt: Number of short messages originally submitted. This is only relevant when the original message was submitted to a distribution list.The value is padded with leading zeros if necessary. |
CamelSmppDestAddr
| only for deliver sm and data sm: Defines the destination SME address. For mobile terminated messages, this is the directory number of the recipient MS. |
CamelSmppScheduleDeliveryTime
| only for deliver sm and data sm: This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC. It can be specified in either absolute time format or relative time format. The encoding of a time format is specified in Section 7.1.1. in the smpp specification v3.4. |
CamelSmppValidityPeriod
| only for deliver sm: The validity period parameter indicates the SMSC expiration time, after which the message should be discarded if not delivered to the destination. It can be defined in absolute time format or relative time format. The encoding of absolute and relative time format is specified in Section 7.1.1 in the smpp specification v3.4. |
CamelSmppServiceType
| only for deliver sm and data sm: The service type parameter indicates the SMS Application service associated with the message. |
CamelSmppRegisteredDelivery
|
only for data sm: Is used to request an delivery
receipt and/or SME originated acknowledgements. The following values are defined:
|
CamelSmppDestAddrNpi
|
only for data sm: Defines the numeric plan
indicator (NPI) in the destination address parameters. The following NPI values are
defined: |
CamelSmppDestAddrTon
|
only for data sm: Defines the type of number (TON)
in the destination address parameters. The following TON values are defined:
|
XMPP — allows for sending and receiving messages over the XMPP transport
The XMPP component implements an XMPP (Jabber) transport. It supports both room based and private person-person conversations. The component supports both producers and consumers.
The URI scheme for an XMPP endpoint is as follows:
xmpp://[login@]hostname[:port][/participant][?options]
Table 7.15 lists the options for an XMPP endpoint.
Table 7.15. XMPP options
| Name | Default | Description |
|---|---|---|
room | Specifies the room to join when connecting to a MUC(Multi User Chat). | |
user | Specifies the username. If not specified, anonymous login will be attempted. | |
password | Specifies the password for authentication. | |
resource | Camel | Specifies the XMPP resource. |
createAccount | false | Specifies if the endpoint will attempt to create an account on the server. |
participant | Specifies Jabber ID of the person to receive messages. [a] | |
nickname | Specifies the nickname to use when joining a room. If no value is given, the
value of user will be used for the nickname. | |
serviceName | Specifies the name of the service you are to which you are connecting. | |
[a] The | ||
Quartz — provides a scheduled delivery of messages using the Quartz scheduler
Maven users will need to add the dependency shown in Example 8.1 to
their pom.xml to use this component.
Example 8.1. Quartz dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-quartz</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>quartz://groupName/timerName?optionsquartz://groupName/timerName/?cron=expression&optionsquartz://timerName?optionsquartz://timerName?cron=expression&options
The component uses either a CronTrigger or a
SimpleTrigger. If no cron expression is provided, the component uses a
simple trigger. If no groupName is provided, the quartz component uses the
Camel group name.
Table 8.1 lists the options for a Quartz endpoint.
Table 8.1. Quartz options
| Parameter | Default | Description |
|---|---|---|
cron | Specifies a cron expression. This option is not compatible with the
trigger.\* or job.\* options. | |
trigger.repeatCount | 0 | Specifies how many times the timer repeats. |
trigger.repeatInterval | 0 | Specifies the amount of time, in milliseconds, between repeated triggers. |
job.name | Specifies the job name. | |
job. | Specifies the job option with the XXX setter
name. | |
trigger. | Specifies the trigger option with the XXX setter
name. | |
stateful | false | Specifies if the timer uses a Quartz StatefulJob instead of the
default job. |
fireNow | false | Specifies if the endpoint will fire the trigger at route start-up when using
SimpleTrigger. |
By default Quartz will look for a quartz.properties file in the
root of the classpath. If you deploy your route as a WAR, the default location for the
quartz.properties file is WEB-INF/classes.
The Quartz endpoint allows you to configure properties using either a URI option or Spring XML configuration. Table 8.2 lists the options for setting the Quartz properties.
Table 8.2. Quartz properties options
| Name | Type | Description |
|---|---|---|
properties | Properties | Specifies a java.util.Propoperties instance containing the
Quartz properties. |
propertiesFile | String | Specifies the file name of the properties to load from the classpath. |
Example 8.2 show how to set the file name in Spring XML.
Example 8.2. Setting the Quartz properties
<bean id="quartz" class="org.apache.camel.component.quartz.QuartzComponent"> <property name="propertiesFile" value="com/mycompany/myquartz.properties"/> </bean>
The Quartz endpoint can configure the Quartz scheduler be started delayed, or not auto started at all. Table 8.3 lists the options for configuring how the Quartz scheduler is started.
Table 8.3. Quartz scheduler start up options
| Name | Default | Description |
|---|---|---|
startDelayedSeconds | 0 | Specifies the number of seconds to wait before starting the quartz scheduler. |
autoStartScheduler | true | Specifies if the scheduler should be auto started. |
Example 8.3 show how to set the scheduler delay in Spring XML.
Example 8.3. Setting the Quartz scheduler delay
<bean id="quartz" class="org.apache.camel.component.quartz.QuartzComponent"> <property name="startDelayedSeconds" value="5"/> </bean>
Apache Camel adds the getters from the Quartz Execution Context as header values. The
following headers are added: calendar, fireTime,
jobDetail, jobInstance,
jobRuntTime, mergedJobDataMap,
nextFireTime, previousFireTime,
refireCount, result,
scheduledFireTime, scheduler,
trigger, triggerName,
triggerGroup.
The fireTime header contains the java.util.Date of
when the exchange was fired.
Timer — generates message exchanges when a timer fires
The URI format for a Timer endpoint is:
timer:name[?options]
name is the name of the Timer object.
Table 8.4 lists the options for a Timer endpoint.
Table 8.4. Timer options
| Name | Default | Description |
|---|---|---|
time | Specifies the date when the first event should
be generated. If using the URI, the pattern expected is: yyyy-MM-dd
HH:mm:ss or yyyy-MM-dd'T'HH:mm:ss. | |
pattern | Allows you to specify a custom date pattern to use for setting the time option using URI syntax. | |
period | 1000 | Specifies the period, in milliseconds, at which events are generated. |
delay | 0 | Specifies the number of milliseconds to wait before the first event is
generated. This option should not be used in conjunction with the
time option. |
fixedRate | false | Specifies if events take place at approximately regular intervals separated by the specified period. |
daemon | true | Specifies whether or not the thread associated with the timer endpoint runs as a daemon. |
When the timer is fired, it adds the following information as properties to the
Exchange:
| Name | Type | Description |
|---|---|---|
org.apache.camel.timer.name | String | The value of the name option. |
org.apache.camel.timer.time | Date | The value of the time option. |
org.apache.camel.timer.period | long | The value of the period option. |
org.apache.camel.timer.firedTime | Date | The time when the consumer fired. |
Mock — provides a declarative framework for testing routes
Mock endpoints provide a powerful declarative testing mechanism similar to jMock. It allows declarative expectations to be created on any Mock endpoint before a test begins. When the test is run, which typically fires messages to one or more endpoints, the expectations can be asserted in a test case to ensure the system worked as expected.
This allows you to test things like:
The correct number of messages are received on each endpoint
The correct payloads are received
The messages arrive on an endpoint in the right order
| Note |
|---|---|
The Test endpoint is a mock endpoint that uses a second endpoint to provide the list of expected message bodies and automatically sets up the mock endpoint assertions. |
Maven users will need to add the dependency shown in Example 9.1 to their
pom.xml to use this component.
Example 9.1. Mock dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-test</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Mock endpoints have the following URI format:
mock:someName[?options]
someName can be any string that uniquely identifies the
endpoint.
Table 9.1 describes the options for a mock endpoint.
Table 9.1. Mock options
| Option | Description |
|---|---|
reportGroup | Specifies a size to use for a throughput logger for reporting. |
Test — a mock endpoint that tests messages based on a set of expected messages
The test endpoint extends the mock endpoint to support pulling messages from another endpoint on startup to set the expected message bodies. That is, you use the test endpoint in a route and messages arriving on it will be implicitly compared to some expected messages extracted from some other location.
Maven users will need to add the dependency shown in Example 9.2 to their
pom.xml to use this component.
Example 9.2. Test dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-test</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>The Atom component is used for polling atom feeds.
Apache Camel will poll the feed every 60 seconds by default.
| Note |
|---|---|
The component currently only supports polling (consuming) feeds. |
Maven users will need to add the dependency shown in Example 10.1 to their
pom.xml to use this component.
Example 10.1. Atom dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-atom</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>The URI format for an Atom endpoint is:
atom://atomUri[?options]atomUri specifies the URI to the Atom feed to poll.
Table 10.1 list the options for the Atom endpoint.
Table 10.1. Atom Component Options
| Property | Default | Description |
|---|---|---|
splitEntries | true | If true Apache Camel will poll the feed and for the subsequent polls
return each entry poll by poll. If the feed contains 7 entries then Apache Camel will return
the first entry on the first poll, the 2nd entry on the next poll, until no more entries
where as Apache Camel will do a new update on the feed. If false then
Apache Camel will poll a fresh feed on every invocation. |
filter
| true
| Is only used by the split entries to filter the entries to return. Apache Camel will
default use the UpdateDateFilter that only return new entries from the
feed. So the client consuming from the feed never receives the same entry more than once.
The filter will return the entries ordered by the newest last. |
lastUpdate
| null
| Is only used by the filter, as the starting timestamp for selection never entries (uses
the entry.updated timestamp). Syntax format is:
yyyy-MM-ddTHH:MM:ss. Example: 2007-12-24T17:45:59.
|
throttleEntries
| true
| Sets whether all entries identified in a single feed poll should be delivered immediately. If true,
only one entry is processed per consumer.delay. Only applicable when splitEntries is set
to true. |
feedHeader
| true
| Sets whether to add the Abdera Feed object as a header. |
sortEntries
| false
| If splitEntries is true, this sets whether to
sort those entries by updated date. |
consumer.delay
| 60000 | Delay in milliseconds between each poll. |
consumer.initialDelay
| 1000 | Specifies the number of milliseconds before polling starts. |
consumer.userFixedDelay
| false
| If true, use fixed delay between pools, otherwise fixed rate is
used. See ScheduledExecutorService in JDK for details. |
Apache Camel will set the In body on the returned Exchange with the
entries. Depending on the splitEntries flag Apache Camel will either return one
Entry or a List<Entry>.
| Option | Value | Behavior |
|---|---|---|
splitEntries
|
true
|
Only a single entry from the currently being processed feed is set:
exchange.in.body(Entry)
|
splitEntries
|
false
|
The entire list of entries from the feed is set:
exchange.in.body(List<Entry>)
|
Apache Camel can set the Feed object on the in header (see
feedHeader option to disable this):
Apache Camel atom uses these headers.
| Header | Description |
|---|---|
org.apache.camel.component.atom.feed
|
Apache Camel 1.x: When consuming the org.apache.abdera.model.Feed object
is set to this header. |
CamelAtomFeed
|
Apache Camel 2.0: When consuming the org.apache.abdera.model.Feed object
is set to this header. |
In the following sample we poll James Strachan's blog:
from("atom://http://macstrac.blogspot.com/feeds/posts/default").to("seda:feeds");In this sample we want to filter only good blogs we like to a SEDA queue. The sample also shows how to set up Apache Camel standalone, not running in any container or using Spring.
@Override
protected CamelContext createCamelContext() throws Exception {
// We initialize Camel
SimpleRegistry registry = new SimpleRegistry();
// First we register a blog service in our bean registry
registry.put("blogService", new BlogService());
// Then we create the camel context with our bean registry
context = new DefaultCamelContext(registry);
// Then we add all the routes we need using the route builder DSL syntax
context.addRoutes(createRouteBuilder());
// And finally we must start Camel to let the magic routing begins
context.start();
return context;
}
/**
* This is the route builder where we create our routes in the advanced Camel DSL syntax
*/
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
public void configure() throws Exception {
// We pool the atom feeds from the source for further processing in the seda queue
// we set the delay to 1 second for each pool as this is a unit test also and we can
// not wait the default poll interval of 60 seconds.
// Using splitEntries=true will during polling only fetch one Atom Entry at any given time.
// As the feed.atom file contains 7 entries, using this will require 7 polls to fetch the entire
// content. When Camel have reach the end of entries it will refresh the atom feed from URI source
// and restart - but as Camel by default uses the UpdatedDateFilter it will only deliver new
// blog entries to "seda:feeds". So only when James Straham updates his blog with a new entry
// Camel will create an exchange for the seda:feeds.
from("atom:file:src/test/data/feed.atom?splitEntries=true&consumer.delay=1000").to("seda:feeds");
// From the feeds we filter each blot entry by using our blog service class
from("seda:feeds").filter().method("blogService", "isGoodBlog").to("seda:goodBlogs");
// And the good blogs is moved to a mock queue as this sample is also used for unit testing
// this is one of the strengths in Camel that you can also use the mock endpoint for your
// unit tests
from("seda:goodBlogs").to("mock:result");
}
};
}
/**
* This is the actual junit test method that does the assertion that our routes is working
* as expected
*/
@Test
public void testFiltering() throws Exception {
// Get the mock endpoint
MockEndpoint mock = context.getEndpoint("mock:result", MockEndpoint.class);
// There should be two good blog entries from the feed
mock.expectedMinimumMessageCount(2);
// Asserts that the above expectations is true, will throw assertions exception if it failed
// Camel will default wait max 20 seconds for the assertions to be true, if the conditions
// is true sooner Camel will continue
mock.assertIsSatisfied();
}
/**
* Services for blogs
*/
public class BlogService {
/**
* Tests the blogs if its a good blog entry or not
*/
public boolean isGoodBlog(Exchange exchange) {
Entry entry = exchange.getIn().getBody(Entry.class);
String title = entry.getTitle();
// We like blogs about Camel
boolean good = title.toLowerCase().contains("camel");
return good;
}
}
bean:beanID[?options]
Where beanID can be any string which is used to lookup look up the bean in the Registry
| Name | Type | Default | Description |
|---|---|---|---|
method
|
String
|
null
|
The method name that bean will be invoked. If not provided, Apache Camel will try to pick the method itself. In case of ambiguity an exception is thrown. See Bean Binding for more details. |
cache
|
boolean
|
false
|
If enabled, Apache Camel will cache the result of the first Registry look-up. Cache can be enabled if the bean in the Registry is defined as a singleton scope. |
multiParameterArray
|
boolean
|
false
|
Apache Camel 1.5: How to treat the parameters which are
passed from the message body; if it is true, the In message body should
be an array of parameters. |
You can append query options to the URI in the following format,
?option=value&option=value&...
The object instance that is used to consume messages must be explicitly registered with
the Registry. For example, if you are using Spring you must
define the bean in the Spring configuration, spring.xml; or if you don't
use Spring, put the bean in JNDI.
// lets populate the context with the services we need
// note that we could just use a spring.xml file to avoid this step
JndiContext context = new JndiContext();
context.bind("bye", new SayService("Good Bye!"));
CamelContext camelContext = new DefaultCamelContext(context);
Once an endpoint has been registered, you can build routes that use it to process exchanges.
// lets add simple route
camelContext.addRoutes(new RouteBuilder() {
public void configure() {
from("direct:hello").to("bean:bye");
}
});
A bean: endpoint cannot be defined as the input to the route; i.e. you cannot consume from it, you can only route from some inbound message Endpoint to the bean endpoint as output. So consider using a direct: or queue: endpoint as the input.
You can use the createProxy() methods on ProxyHelper to create a proxy that will generate BeanExchanges and send them to any
endpoint:
Endpoint endpoint = camelContext.getEndpoint("direct:hello");
ISay proxy = ProxyHelper.createProxy(endpoint, ISay.class);
String rc = proxy.say();
assertEquals("Good Bye!", rc);
And the same route using XML DSL:
<route>
<from uri="direct:hello">
<to uri="bean:bye"/>
</route>Apache Camel also supports invoking Bean as an Endpoint. In the route below:
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<to uri="myBean"/>
<to uri="mock:results"/>
</route>
</camelContext>
<bean id="myBean" class="org.apache.camel.spring.bind.ExampleBean"/>
What happens is that when the exchange is routed to the myBean Apache Camel
will use the Bean Binding to invoke the bean. The source
for the bean is just a plain POJO:
public class ExampleBean {
public String sayHello(String name) {
return "Hello " + name + "!";
}
}
Apache Camel will use Bean Binding to invoke the
sayHello method, by converting the Exchange's In body to the
String type and storing the output of the method on the Exchange Out
body.
How bean methods to be invoked are chosen (if they are not specified explicitly through
the method parameter) and how parameter values are
constructed from the Message are all defined by the Bean Binding mechanism which is used throughout all of the
various Bean Integration mechanisms in
Apache Camel.
Class component
Available as of Apache Camel 2.3
The Validation component performs bean validation of the message body using the Java Bean Validation API (JSR 303). Apache Camel uses the reference implementation, which is Hibernate Validator.
Maven users will need to add the following dependency to their
pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-bean-validator</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>bean-validator:something[?options]
or
bean-validator://something[?options]
Where something must be present to provide a valid
URL. You can append query options to the URI in the following format,
?option=value&option=value&...
The following URI options are supported:
| Option | Default | Description |
|---|---|---|
group
|
javax.validation.groups.Default
|
The custom validation group to use. |
messageInterpolator
|
org.hibernate.validator.engine.
ResourceBundleMessageInterpolator
|
Reference to a custom javax.validation.MessageInterpolator
in the Registry. |
traversableResolver
|
org.hibernate.validator.engine.resolver.
DefaultTraversableResolver
|
Reference to a custom javax.validation.TraversableResolver
in the Registry. |
constraintValidatorFactory
|
org.hibernate.validator.engine.
ConstraintValidatorFactoryImpl
|
Reference to a custom
javax.validation.ConstraintValidatorFactory in the Registry. |
Assumed we have a java bean with the following annotations
| Car.java |
|---|---|
// Java
public class Car {
@NotNull
private String manufacturer;
@NotNull
@Size(min = 5, max = 14, groups = OptionalChecks.class)
private String licensePlate;
// getter and setter
} |
and an interface definition for our custom validation group
| OptionalChecks.java |
|---|---|
public interface OptionalChecks {
} |
with the following Apache Camel route, only the @NotNull
constraints on the attributes manufacturer and licensePlate will be validated (Apache Camel
uses the default group javax.validation.groups.Default).
from("direct:start")
.to("bean-validator://x")
.to("mock:end")If you want to check the constraints from the group OptionalChecks,
you have to define the route like this
from("direct:start")
.to("bean-validator://x?group=OptionalChecks")
.to("mock:end")If you want to check the constraints from both groups, you have to define a new interface first
| AllChecks.java |
|---|---|
@GroupSequence({Default.class, OptionalChecks.class})
public interface AllChecks {
} |
and then your route definition should looks like this
from("direct:start")
.to("bean-validator://x?group=AllChecks")
.to("mock:end")And if you have to provide your own message interpolator, traversable resolver and constraint validator factory, you have to write a route like this
<bean id="myMessageInterpolator" class="my.ConstraintValidatorFactory" />
<bean id="myTraversableResolver" class="my.TraversableResolver" />
<bean id="myConstraintValidatorFactory" class="my.ConstraintValidatorFactory" />
from("direct:start")
.to("bean-validator://x?group=AllChecks&messageInterpolator=#myMessageInterpolator&traversableResolver=#myTraversableResolver&constraintValidatorFactory=#myConstraintValidatorFactory")
.to("mock:end")It's also possible to describe your constraints as XML and not as Java annotations. In
this case, you have to provide the file META-INF/validation.xml which
could looks like this
| validation.xml |
|---|---|
<?xml version="1.0" encoding="UTF-8"?> <validation-config xmlns="http://jboss.org/xml/ns/javax/validation/configuration" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration"> <default-provider>org.hibernate.validator.HibernateValidator</default-provider> <message-interpolator>org.hibernate.validator.engine.ResourceBundleMessageInterpolator</message-interpolator> <traversable-resolver>org.hibernate.validator.engine.resolver.DefaultTraversableResolver</traversable-resolver> <constraint-validator-factory>org.hibernate.validator.engine.ConstraintValidatorFactoryImpl</constraint-validator-factory> <constraint-mapping>/constraints-car.xml</constraint-mapping> </validation-config> |
and the constraints-car.xml file
| constraints-car.xml |
|---|---|
<?xml version="1.0" encoding="UTF-8"?> <constraint-mappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd" xmlns="http://jboss.org/xml/ns/javax/validation/mapping"> <default-package>org.apache.camel.component.bean.validator</default-package> <bean class="CarWithoutAnnotations" ignore-annotations="true"> <field name="manufacturer"> <constraint annotation="javax.validation.constraints.NotNull" /> </field> <field name="licensePlate"> <constraint annotation="javax.validation.constraints.NotNull" /> <constraint annotation="javax.validation.constraints.Size"> <groups> <value>org.apache.camel.component.bean.validator.OptionalChecks</value> </groups> <element name="min">5</element> <element name="max">14</element> </constraint> </field> </bean> </constraint-mappings> |
Available as of Apache Camel 2.0
The Browse component provides a simple BrowsableEndpoint which can be useful for testing, visualisation tools or debugging. The exchanges sent to the endpoint are all available to be browsed.
In the route below, we insert a browse: component to be able to
browse the Exchanges that are passing through:
from("activemq:order.in").to("browse:orderReceived").to("bean:processOrder");We can now inspect the received exchanges from within the Java code:
private CamelContext context;
public void inspectRecievedOrders() {
BrowsableEndpoint browse = context.getEndpoint("browse:orderReceived", BrowsableEndpoint.class);
List<Exchange> exchanges = browse.getExchanges();
...
// then we can inspect the list of received exchanges from Java
for (Exchange exchange : exchanges) {
String payload = exchange.getIn().getBody();
...
}
}
Available as of Apache Camel 2.1
The cache component enables you to perform caching operations using EHCache as the Cache Implementation. The cache itself is created on demand or if a cache of that name already exists then it is simply utilized with its original settings.
This component supports producer and event based consumer endpoints.
The Cache consumer is an event based consumer and can be used to listen and respond to specific cache activities. If you need to perform selections from a pre-existing cache, used the processors defined for the cache component.
cache://cacheName[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
maxElementsInMemory
|
1000
|
The numer of elements that may be stored in the defined cache |
memoryStoreEvictionPolicy
|
MemoryStoreEvictionPolicy.LFU
|
The number of elements that may be stored in the defined cache. The policy options include:
|
overflowToDisk
|
true
|
Specifies whether cache may overflow to disk. |
eternal
|
false
|
Sets whether elements are eternal. If eternal, timeouts are ignored and the element is never expired. |
timeToLiveSeconds
|
300
|
The maximum time between creation time and when an element expires. Is only used if the element is not eternal. |
timeToIdleSeconds
|
300
|
The maximum amount of time between accesses before an element expires. |
diskPersistent
|
true
|
Whether the disk store persists between restarts of the Virtual Machine. The default
value is false. |
diskExpiryThreadIntervalSeconds
|
120
|
The number of seconds between runs of the disk expiry thread. The default value is 120 seconds. |
cacheManagerFactory
|
null
|
Camel 2.3: If you want to use a custom factory which
instantiates and creates the EHCache net.sf.ehcache.CacheManager. |
| Header | Description |
|---|---|
CACHE_OPERATION
|
The operation to be performed on the cache. The valid options are:
|
CACHE_KEY
|
The cache key used to store the message in the cache. The cache key is optional, if the
CACHE_OPERATION is DELETEALL. |
Sending data to the cache involves the ability to direct payloads in exchanges to be stored in a pre-existing or created-on- demand cache. The mechanics of doing this involve - setting the Message Exchange Headers shown above. - ensuring that the Message Exchange Body contains the message directed to the cache
Receiving data from the cache involves the ability of the CacheConsumer to
listen on a pre-existing or created-on-demand Cache using an event Listener and receive
automatic notifications when any cache activity take place (i.e
ADD/UPDATE/DELETE/DELETEALL). Upon such
an activity taking place - an exchange containing Message Exchange Headers and a Message
Exchange Body containing the just added/updated payload is placed and sent. - in case of a
DELETEALL operation, the Message Exchange Header CACHE_KEY and the
Message Exchange Body are not populated.
There are a set of nice processors with the ability to perform cache lookups and selectively replace payload content at the - body - token - xpath level
from("cache://MyApplicationCache" +
"?maxElementsInMemory=1000" +
"&memoryStoreEvictionPolicy=" +
"MemoryStoreEvictionPolicy.LFU" +
"&overflowToDisk=true" +
"&eternal=true" +
"&timeToLiveSeconds=300" +
"&timeToIdleSeconds=true" +
"&diskPersistent=true" +
"&diskExpiryThreadIntervalSeconds=300")
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start")
.setHeader("CACHE_OPERATION", constant("ADD"))
.setHeader("CACHE_KEY", constant("Ralph_Waldo_Emerson"))
.to("cache://TestCache1")
}
};
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start")
.setHeader("CACHE_OPERATION", constant("UPDATE"))
.setHeader("CACHE_KEY", constant("Ralph_Waldo_Emerson"))
.to("cache://TestCache1")
}
};
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start")
.setHeader("CACHE_OPERATION", constant("DELETE"))
.setHeader("CACHE_KEY", constant("Ralph_Waldo_Emerson"))
.to("cache://TestCache1")
}
};
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start")
.setHeader("CACHE_OPERATION", constant("DELETEALL"))
.to("cache://TestCache1");
}
};
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("cache://TestCache1")
.process(new Processor() {
public void process(Exchange exchange)
throws Exception {
String operation = (String) exchange.getIn().getHeader("CACHE_OPERATION");
String key = (String) exchange.getIn().getHeader("CACHE_KEY");
Object body = exchange.getIn().getBody();
// Do something
}
})
}
};
RouteBuilder builder = new RouteBuilder() {
public void configure() {
//Message Body Replacer
from("cache://TestCache1")
.filter(header("CACHE_KEY").isEqualTo("greeting"))
.process(new CacheBasedMessageBodyReplacer("cache://TestCache1","farewell"))
.to("direct:next");
//Message Token replacer
from("cache://TestCache1")
.filter(header("CACHE_KEY").isEqualTo("quote"))
.process(new CacheBasedTokenReplacer("cache://TestCache1","novel","#novel#"))
.process(new CacheBasedTokenReplacer("cache://TestCache1","author","#author#"))
.process(new CacheBasedTokenReplacer("cache://TestCache1","number","#number#"))
.to("direct:next");
//Message XPath replacer
from("cache://TestCache1").
.filter(header("CACHE_KEY").isEqualTo("XML_FRAGMENT"))
.process(new CacheBasedXPathReplacer("cache://TestCache1","book1","/books/book1"))
.process (new CacheBasedXPathReplacer("cache://TestCache1","book2","/books/book2"))
.to("direct:next");
}
};from("direct:start")
// Prepare headers
.setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_GET))
.setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson")).
.to("cache://TestCache1").
// Check if entry was not found
.choice().when(header(CacheConstants.CACHE_ELEMENT_WAS_FOUND).isNull()).
// If not found, get the payload and put it to cache
.to("cxf:bean:someHeavyweightOperation").
.setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD))
.setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson"))
.to("cache://TestCache1")
.end()
.to("direct:nextPhase");Note: CHECK command tests existence of the entry in the cache but doesn't place message to the body.
from("direct:start")
// Prepare headers
.setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_CHECK))
.setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson")).
.to("cache://TestCache1").
// Check if entry was not found
.choice().when(header(CacheConstants.CACHE_ELEMENT_WAS_FOUND).isNull()).
// If not found, get the payload and put it to cache
.to("cxf:bean:someHeavyweightOperation").
.setHeader(CacheConstants.CACHE_OPERATION, constant(CacheConstants.CACHE_OPERATION_ADD))
.setHeader(CacheConstants.CACHE_KEY, constant("Ralph_Waldo_Emerson"))
.to("cache://TestCache1")
.end();EHCache has its own statistics and management from JMX.
Here's a snippet on how to expose them via JMX in a Spring application context:
<bean id="ehCacheManagementService" class="net.sf.ehcache.management.ManagementService" init-method="init" lazy-init="false">
<constructor-arg>
<bean class="net.sf.ehcache.CacheManager" factory-method="getInstance"/>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.jmx.support.JmxUtils" factory-method="locateMBeanServer"/>
</constructor-arg>
<constructor-arg value="true"/>
<constructor-arg value="true"/>
<constructor-arg value="true"/>
<constructor-arg value="true"/>
</bean>
Of course you can do the same thing in straight Java:
ManagementService.registerMBeans(CacheManager.getInstance(), mbeanServer, true, true, true, true);
You can get cache hits, misses, in-memory hits, disk hits, size stats this way. You can also change CacheConfiguration parameters on the fly.
The class: component binds beans to message exchanges. It works in the same way as the Bean component but instead of looking up beans from a Registry it creates the bean based on the class name.
class:className[?options]
Where className is the fully qualified class name to create and use as bean.
| Name | Type | Default | Description |
|---|---|---|---|
method
|
String
|
null
|
The method name that bean will be invoked. If not provided, Apache Camel will try to pick the method itself. In case of ambiguity an exception is thrown. See Bean Binding for more details. |
multiParameterArray
|
boolean
|
false
|
How to treat the parameters which are passed from the message body; if it is true, the In message body should be an array of parameters. |
You can append query options to the URI in the following format, ?option=value&option=value&...
You simply use the class component just as the Bean component but by specifying the fully qualified classname instead.
For example to use the MyFooBean you have to do as follows:
from("direct:start").to("class:org.apache.camel.component.bean.MyFooBean").to("mock:result");
You can also specify which method to invoke on the MyFooBean, for example hello:
from("direct:start").to("class:org.apache.camel.component.bean.MyFooBean?method=hello").to("mock:result");
In the endpoint uri you can specify properties to set on the created instance, for example if it has a setPrefix method:
from("direct:start")
.to("class:org.apache.camel.component.bean.MyPrefixBean?prefix=Bye")
.to("mock:result");
And you can also use the # syntax to refer to properties to be looked up in the Registry.
from("direct:start")
.to("class:org.apache.camel.component.bean.MyPrefixBean?cool=#foo")
.to("mock:result");
Which will lookup a bean from the Registry with the id foo and invoke the setCool method on the created instance of the MyPrefixBean class.
| See more |
|---|---|
See more details at the Bean component as the class component works in much the same way. |
The cometd: component is a transport for working with the jetty implementation of the cometd/bayeux protocol. Using this component in combination with the dojo toolkit library it's possible to push Apache Camel messages directly into the browser using an AJAX based mechanism.
cometd://host:port/channelName[?options]
The channelName represents a topic that can be subscribed to by the Apache Camel endpoints.
cometd://localhost:8080/service/mychannel cometds://localhost:8443/service/mychannel
where cometds: represents an SSL configured endpoint.
See this blog entry by David Greco who contributed this component to Apache Camel, for a full sample.
| Name | Default Value | Description |
|---|---|---|
resourceBase
|
The root directory for the web resources or classpath. Use the protocol file: or classpath: depending if you want that the component loads the resource from file system or classpath. Classpath is required for OSGI deployment where the resources are packaged in the jar | |
timeout
|
240000
|
The server side poll timeout in milliseconds. This is how long the server will hold a reconnect request before responding. |
interval
|
0
|
The client side poll timeout in milliseconds. How long a client will wait between reconnects |
maxInterval
|
30000
|
The max client side poll timeout in milliseconds. A client will be removed if a connection is not received in this time. |
multiFrameInterval
|
1500
|
The client side poll timeout, if multiple connections are detected from the same browser. |
jsonCommented
|
true
|
If true, the server will accept JSON wrapped in a comment
and will generate JSON wrapped in a comment. This is a defence against Ajax
Hijacking. |
logLevel
|
1
|
0=none, 1=info,
2=debug. |
You can append query options to the URI in the following format,
?option=value&option=value&...
Here is some examples of how to pass the parameters.
For file (when the Webapp resources are located in the Web Application directory) cometd://localhost:8080?resourceBase=file./webapp.
For classpath (when the web resources are packaged inside the Webapp folder) cometd://localhost:8080?resourceBase=classpath:webapp.
Available as of Camel 2.7
The context component allows you to create new Camel Components from a CamelContext with a number of routes which is then treated as a black box, allowing you to refer to the local endpoints within the component from other CamelContexts.
It is similar to the Routebox component in idea, though the Context component tries to be really simple for end users; just a simple convention over configuration approach to refer to local endpoints inside the CamelContext Component.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-context</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
context:camelContextId:localEndpointName[?options]
Or you can omit the "context:" prefix.
camelContextId:localEndpointName[?options]
camelContextId is the ID you used to register the CamelContext into the Registry.
localEndpointName can be a valid Camel URI evaluated within the black box CamelContext. Or it can be a logical name which is mapped to any local endpoints. For example if you locally have endpoints like direct:invoices and seda:purchaseOrders inside a CamelContext of id supplyChain, then you can just use the URIs supplyChain:invoices or supplyChain:purchaseOrders to omit the physical endpoint kind and use pure logical URIs.
You can append query options to the URI in the following format, ?option=value&option=value&...
In this example we'll create a black box context, then we'll use it from another CamelContext.
First you need to create a CamelContext, add some routes in it, start it and then register the CamelContext into the Registry (JNDI, Spring, Guice or OSGi etc).
This can be done in the usual Camel way from this test case (see the createRegistry() method); this example shows Java and JNDI being used...
// lets create our black box as a camel context and a set of routes
DefaultCamelContext blackBox = new DefaultCamelContext(registry);
blackBox.setName("blackBox");
blackBox.addRoutes(new RouteBuilder() {
@Override
public void configure() throws Exception {
// receive purchase orders, lets process it in some way then send an invoice
// to our invoice endpoint
from("direct:purchaseOrder").
setHeader("received").constant("true").
to("direct:invoice");
}
});
blackBox.start();
registry.bind("accounts", blackBox);
Notice in the above route we are using pure local endpoints (direct and seda). Also note we expose this CamelContext using the accounts ID. We can do the same thing in XML via
<camelContext id="accounts" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:purchaseOrder"/>
...
<to uri="direct:invoice"/>
</route>
</camelContext>
Then in another CamelContext we can then refer to this "accounts black box" by just sending to accounts:purchaseOrder and consuming from accounts:invoice.
If you prefer to be more verbose and explicit you could use context:accounts:purchaseOrder or even context:accounts:direct://purchaseOrder if you prefer. But using logical endpoint URIs is preferred as it hides the implementation detail and provides a simple logical naming scheme.
For example if we wish to then expose this accounts black box on some middleware (outside of the black box) we can do things like...
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<!-- consume from an ActiveMQ into the black box -->
<from uri="activemq:Accounts.PurchaseOrders"/>
<to uri="accounts:purchaseOrders"/>
</route>
<route>
<!-- lets send invoices from the black box to a different ActiveMQ Queue -->
<from uri="accounts:invoice"/>
<to uri="activemq:UK.Accounts.Invoices"/>
</route>
</camelContext>
A context component instance can have many public input and output endpoints that can be accessed from outside it's CamelContext. When there are many it is recommended that you use logical names for them to hide the middleware as shown above.
However when there is only one input, output or error/dead letter endpoint in a component we recommend using the common posix shell names in, out and err
Using Apache Camel cryptographic endpoints and Java's Cryptographic extension it is easy to create Digital Signatures for Exchanges. Apache Camel provides a pair of flexible endpoints which get used in concert to create a signature for an exchange in one part of the exchange's workflow and then verify the signature in a later part of the workflow.
Maven users will need to add the following dependency to their pom.xml
for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-crypto</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>Digital signatures make use Asymmetric Cryptographic techniques to sign messages. From a (very) high level, the algorithms use pairs of complimentary keys with the special property that data encrypted with one key can only be decrypted with the other. One, the private key, is closely guarded and used to 'sign' the message while the other, public key, is shared around to anyone interested in verifying your messages. Messages are signed by encrypting a digest of the message with the private key. This encrypted digest is transmitted along with the message. On the other side the verifier recalculates the message digest and uses the public key to decrypt the the digest in the signature. If both digest match the verifier knows only the holder of the private key could have created the signature.
Apache Camel uses the Signature service from the Java Cryptographic Extension to do all the heavy cryptographic lifting required to create exchange signatures. The following are some excellent sources for explaining the mechanics of Cryptography, Message digests and Digital Signatures and how to leverage them with the JCE.
Bruce Schneier's Applied Cryptography
Beginning Cryptography with Java by David Hook
The ever insightful, Wikipedia Digital_signatures
As mentioned Apache Camel provides a pair of crypto endpoints to create and verify signatures
crypto:sign:name[?options] crypto:verify:name[?options]
crypto:sign creates the signature and stores it in the Header keyed
by the constant Exchange.SIGNATURE, i.e.
"CamelDigitalSignature".
crypto:verify will read in the contents of this header and do the
verification calculation.
In order to correctly function, sign and verify need to share a pair of keys, sign
requiring a PrivateKey and verify a PublicKey (or a
Certificate containing one). Using the JCE is is very simple to generate
these key pairs but it is usually most secure to use a KeyStore to house and share your keys.
The DSL is very flexible about how keys are supplied and provides a number of mechanisms.
Note a crypto:sign endpoint is typically defined in one route and the
complimentary crypto:verify in another, though for simplicity in the
examples they appear one after the other. It goes without saying that both sign and verify
should be configured identically.
| Name | Type | Default | Description |
|---|---|---|---|
algorithm
|
String
|
DSA
|
The name of the JCE Signature algorithm that will be used. |
alias
|
String
|
null
|
An alias name that will be used to select a key from the keystore. |
bufferSize
|
Integer
|
2048
|
the size of the buffer used in the signature process. |
certificate
|
Certificate
|
null
|
A Certificate used to verify the signature of the exchange's payload. Either this or a Public Key is required. |
keystore
|
KeyStore
|
null
|
A reference to a JCE Keystore that stores keys and certificates used to sign and verify. |
provider
|
String
|
null
|
The name of the JCE Security Provider that should be used. |
privateKey
|
PrivatKey
|
null
|
The private key used to sign the exchange's payload. |
publicKey
|
PublicKey
|
null
|
The public key used to verify the signature of the exchange's payload. |
secureRandom
|
secureRandom
|
null
|
A reference to a SecureRandom object that wil lbe used to initialize
the Signature service. |
password
|
char[]
|
null
|
The password for the keystore. |
The most basic way to way to sign an verify an exchange is with a KeyPair as follows.
from("direct:keypair").to("crypto:sign://basic?privateKey=#myPrivateKey", "crypto:verify://basic?publicKey=#myPublicKey", "mock:result");The same can be achieved with the Spring XML Extensions using references to keys
<route>
<from uri="direct:keypair"/>
<to uri="crypto:sign://basic?privateKey=#myPrivateKey" />
<to uri="crypto:verify://basic?publicKey=#myPublicKey" />
<to uri="mock:result"/>
</route>The JCE provides a very versatile KeyStore for housing pairs of PrivateKeys and Certificates keeping them encrypted and password protected. They can be retrieved from it by applying an alias to the retrieval apis. There are a number of ways to get keys and Certificates into a keystore most often this is done with the external 'keytool' application. This is a good example of using keytool to create a KeyStore with a self signed Cert and Private key.
The examples use a Keystore with a key and cert aliased by 'bob'. The password for the keystore and the key is 'letmein'
The following shows how to use a Keystore via the Fluent builders, it also shows how to load and initialize the keystore.
from("direct:keystore").to("crypto:sign://keystore?keystore=#keystore&alias=bob&password=letmein", "crypto:verify://keystore?keystore=#keystore&alias=bob", "mock:result");Again in Spring a ref is used to lookup an actual keystore instance.
<route>
<from uri="direct:keystore"/>
<to uri="crypto:sign://keystore?keystore=#keystore&lias=bob&assword=letmein" />
<to uri="crypto:verify://keystore?keystore=#keystore&lias=bob" />
<to uri="mock:result"/>
</route> Changing the Signature algorithm or the Security provider is a simple matter of specifying their names. You will need to also use Keys that are compatible with the algorithm you choose.
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(512, new SecureRandom());
keyPair = keyGen.generateKeyPair();
PrivateKey privateKey = keyPair.getPrivate();
PublicKey publicKey = keyPair.getPublic();
// we can set the keys explicitly on the endpoint instances.
context.getEndpoint("crypto:sign://rsa?algorithm=MD5withRSA", DigitalSignatureEndpoint.class).setPrivateKey(privateKey);
context.getEndpoint("crypto:verify://rsa?algorithm=MD5withRSA", DigitalSignatureEndpoint.class).setPublicKey(publicKey);
from("direct:algorithm").to("crypto:sign://rsa?algorithm=MD5withRSA", "crypto:verify://rsa?algorithm=MD5withRSA", "mock:result");
from("direct:provider").to("crypto:sign://provider?privateKey=#myPrivateKey&provider=SUN", "crypto:verify://provider?publicKey=#myPublicKey&provider=SUN", "mock:result");
or
<route>
<from uri="direct:algorithm"/>
<to uri="crypto:sign://rsa?algorithm=MD5withRSA&rivateKey=#rsaPrivateKey" />
<to uri="crypto:verify://rsa?algorithm=MD5withRSA&ublicKey=#rsaPublicKey" />
<to uri="mock:result"/>
</route>
<route>
<from uri="direct:provider"/>
<to uri="crypto:sign://provider?privateKey=#myPrivateKey&rovider=SUN" />
<to uri="crypto:verify://provider?publicKey=#myPublicKey&rovider=SUN" />
<to uri="mock:result"/>
</route> It may be desirable to change the message header used to store the signature. A different header name can be specified in the route definition as follows
from("direct:signature-header").to("crypto:sign://another?privateKey=#myPrivateKey&signatureHeader=AnotherDigitalSignature",
"crypto:verify://another?publicKey=#myPublicKey&signatureHeader=AnotherDigitalSignature", "mock:result");or
<route>
<from uri="direct:signature-header"/>
<to uri="crypto:sign://another?privateKey=#myPrivateKey&ignatureHeader=AnotherDigitalSignature" />
<to uri="crypto:verify://another?publicKey=#myPublicKey&ignatureHeader=AnotherDigitalSignature" />
<to uri="mock:result"/>
</route> In case you need to update the size of the buffer...
from("direct:buffersize").to("crypto:sign://buffer?privateKey=#myPrivateKey&buffersize=1024", "crypto:verify://buffer?publicKey=#myPublicKey&buffersize=1024", "mock:result");or
<route>
<from uri="direct:buffersize" />
<to uri="crypto:sign://buffer?privateKey=#myPrivateKey&uffersize=1024" />
<to uri="crypto:verify://buffer?publicKey=#myPublicKey&uffersize=1024" />
<to uri="mock:result"/>
</route> When using a Recipient list or similar EIP the recipient of an exchange can vary dynamically. Using the same key across all recipients may neither be feasible or desirable. It would be useful to be able to specify the signature keys dynamically on a per exchange basis. The exchange could then be dynamically enriched with the key of its target recipient prior to signing. To facilitate this the signature mechanisms allow for keys to be supplied dynamically via the message headers below
Exchange.SIGNATURE_PRIVATE_KEY,
"CamelSignaturePrivateKey"
Exchange.SIGNATURE_PUBLIC_KEY_OR_CERT,
"CamelSignaturePublicKeyOrCert"
from("direct:headerkey-sign").to("crypto:sign://alias");
from("direct:headerkey-verify").to("crypto:verify://alias", "mock:result");or
<route>
<from uri="direct:headerkey-sign"/>
<to uri="crypto:sign://headerkey" />
</route>
<route>
<from uri="direct:headerkey-verify"/>
<to uri="crypto:verify://headerkey" />
<to uri="mock:result"/>
</route> Better again would be to dynamically supply a keystore alias. Again the alias can be supplied in a message header
Exchange.KEYSTORE_ALIAS,
"CamelSignatureKeyStoreAlias"
from("direct:alias-sign").to("crypto:sign://alias?keystore=#keystore");
from("direct:alias-verify").to("crypto:verify://alias?keystore=#keystore", "mock:result");or
<route>
<from uri="direct:alias-sign"/>
<to uri="crypto:sign://alias?keystore=#keystore" />
</route>
<route>
<from uri="direct:alias-verify"/>
<to uri="crypto:verify://alias?keystore=#keystore" />
<to uri="mock:result"/>
</route> The header would be set as follows
Exchange unsigned = getMandatoryEndpoint("direct:alias-sign").createExchange();
unsigned.getIn().setBody(payload);
unsigned.getIn().setHeader(DigitalSignatureConstants.KEYSTORE_ALIAS, "bob");
unsigned.getIn().setHeader(DigitalSignatureConstants.KEYSTORE_PASSWORD, "letmein".toCharArray());
template.send("direct:alias-sign", unsigned);
Exchange signed = getMandatoryEndpoint("direct:alias-sign").createExchange();
signed.getIn().copyFrom(unsigned.getOut());
signed.getIn().setHeader(KEYSTORE_ALIAS, "bob");
template.send("direct:alias-verify", signed);See also:
Crypto Crypto is also available as a Data Format
The DataSet component (available since 1.3.0) provides a mechanism to easily perform load & soak testing of your system. It works by allowing you to create DataSet instances both as a source of messages and as a way to assert that the data set is received.
Apache Camel will use the throughput logger when sending dataset's.
dataset:name[?options]
Where name is used to find the DataSet instance in the Registry
Apache Camel ships with a support implementation of
org.apache.camel.component.dataset.DataSet, the
org.apache.camel.component.dataset.DataSetSupport class, that can be
used as a base for implementing your own DataSet. Apache Camel also ships with a default
implementation, the org.apache.camel.component.dataset.SimpleDataSet
that can be used for testing.
| Option | Default | Description |
|---|---|---|
produceDelay
|
3 | Allows a delay in ms to be specified, which causes producers to pause in order to simulate slow producers. Uses a minimum of 3 ms delay unless you set this option to -1 to force no delay at all. |
consumeDelay
|
0 | Allows a delay in ms to be specified, which causes consumers to pause in order to simulate slow consumers. |
preloadSize
|
0 | Sets how many messages should be preloaded (sent) before the route completes its initialization. |
initialDelay
|
1000 | Camel 2.1: Time period in millis to wait before starting sending messages. |
minRate
|
0 | Wait until the DataSet contains at least this number of messages |
You can append query options to the URI in the following format,
?option=value&option=value&...
Apache Camel will lookup in the Registry for a bean implementing the DataSet interface. So you can register your own DataSet as:
<bean id="myDataSet" class="com.mycompany.MyDataSet">
<property name="size" value="100"/>
</bean>For example, to test that a set of messages are sent to a queue and then consumed from the queue without losing any messages:
// send the dataset to a queue
from("dataset:foo").to("activemq:SomeQueue");
// now lets test that the messages are consumed correctly
from("activemq:SomeQueue").to("dataset:foo");The above would look in the Registry to find the foo DataSet instance which is used to create the messages.
Then you create a DataSet implementation, such as using the
SimpleDataSet as described below, configuring things like how big the
data set is and what the messages look like etc.
| Property | Type | Description |
|---|---|---|
defaultBody
|
Object
|
Specifies the default message body. For SimpleDataSet it is a constant
payload; though if you want to create custom payloads per message, create your own
derivation of DataSetSupport. |
reportGroup
|
long
|
Specifies the number of messages to be received before reporting progress. Useful for showing progress of a large load test. |
size
|
long
|
Specifies how many messages to send/consume. |
Available as of Camel 2.5
The db4o: component allows you to work with db4o NoSQL database. The camel-db4o library is provided by the Camel Extra project which hosts all *GPL related components for Camel.
Sending POJO object to the db4o endpoint adds and saves object into the database. The body of the message is assumed to be a POJO that has to be saved into the db40 database store.
Consuming messages removes (or updates) POJO objects in the database. This allows you to use a Db4o datastore as a logical queue; consumers take messages from the queue and then delete them to logically remove them from the queue.
If you do not wish to delete the object when it has been processed, you can specify consumeDelete=false on the URI. This will result in the POJO being processed each poll.
db4o:className[?options]
You can append query options to the URI in the following format, ?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
consumeDelete
|
true
|
Option for Db4oConsumer only. Specifies whether or not the entity is deleted after it is consumed. |
consumer.delay
|
500
|
Option for HibernateConsumer only. Delay in millis between each poll. |
consumer.initialDelay
|
1000
|
Option for HibernateConsumer only. Millis before polling starts. |
consumer.userFixedDelay
|
false
|
Option for HibernateConsumer only. Set to true to use fixed delay between polls, otherwise fixed rate is used. See ScheduledExecutorService in JDK for details. |
Available as of Camel 2.7
This is an additional component for Camel to run DNS queries, using DNSJava. The component is a thin layer on top of DNSJava. The component offers the following operations:
ip, to resolve a domain by its ip
lookup, to lookup information about the domain
dig, to run DNS queries
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-dns</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
The URI scheme for a DNS component is as follows
dns://operation
This component only supports producers.
| Header | Type | Operations | Description |
|---|---|---|---|
| dns.domain | String | ip | The domain name. Mandatory. |
| dns.name | String | lookup | The name to lookup. Mandatory. |
| dns.type | - | lookup, dig | The type of the lookup. Should match the values of org.xbill.dns.Type. Optional. |
| dns.class | - | lookup, dig | he DNS class of the lookup. Should match the values of org.xbill.dns.DClass. Optional. |
| dns.query | String | dig | The query itself. Mandatory. |
| dns.server | String | dig | The server in particular for the query. If none is given, the default one specified by the OS will be used. Optional. |
<route id="IPCheck">
<from uri="direct:start"/>
<to uri="dns:ip"/>
</route>
This looks up a domain's IP. For example, www.example.com resolves to 192.0.32.10.
The IP address to lookup must be provided in the header with key "dns.domain".
<route id="IPCheck">
<from uri="direct:start"/>
<to uri="dns:lookup"/>
</route>
This returns a set of DNS records associated with a domain.
The name to lookup must be provided in the header with key "dns.name".
ejb:ejbName[?options]
Where ejbName can be any string which is used to look up the EJB in the Application Server JNDI Registry
| Name | Type | Default | Description |
|---|---|---|---|
method
|
String
|
null
|
The method name that bean will be invoked. If not provided, Apache Camel will try to pick the method itself. In case of ambiguity an exception is thrown. See Bean Binding for more details. |
multiParameterArray
|
boolean
|
false
|
How to treat the parameters which are passed from the message body; if it is true, the In message body should be an array of parameters. |
You can append query options to the URI in the following format, ?option=value&option=value&...
The EJB component extends the Bean component in which most of the details from the Bean component applies to this component as well.
How bean methods to be invoked are chosen (if they are not specified explicitly through the method parameter) and how parameter values are constructed from the MessageMessage are all defined by the Bean Binding mechanism which is used throughout all of the various Bean Integration mechanisms in Apache Camel.
In the following examples we use the Greater EJB which is defined as follows:
public interface GreaterLocal {
String hello(String name);
String bye(String name);
}
And the implementation
@Stateless
public class GreaterImpl implements GreaterLocal {
public String hello(String name) {
return "Hello " + name;
}
public String bye(String name) {
return "Bye " + name;
}
}
In this example we want to invoke the hello method on the EJB. Since this example is based on an unit test using Apache OpenEJB we have to set a JndiContext on the EJB component with the OpenEJB settings.
@Override
protected CamelContext createCamelContext() throws Exception {
CamelContext answer = new DefaultCamelContext();
// enlist EJB component using the JndiContext
EjbComponent ejb = answer.getComponent("ejb", EjbComponent.class);
ejb.setContext(createEjbContext());
return answer;
}
private static Context createEjbContext() throws NamingException {
// here we need to define our context factory to use OpenEJB for our testing
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");
return new InitialContext(properties);
}
Then we are ready to use the EJB in the Apache Camel route:
from("direct:start")
// invoke the greeter EJB using the local interface and invoke the hello method
.to("ejb:GreaterImplLocal?method=hello")
.to("mock:result");
| In a real application server |
|---|---|
In a real application server you most likely do not have to setup a |
And this is the same example using XML instead:
Again since this is based on an unit test we need to setup the EJB component:
<!-- setup Camel EJB component -->
<bean id="ejb" class="org.apache.camel.component.ejb.EjbComponent">
<property name="properties" ref="jndiProperties"/>
</bean>
<!-- use OpenEJB context factory -->
<p:properties id="jndiProperties">
<prop key="java.naming.factory.initial">org.apache.openejb.client.LocalInitialContextFactory</prop>
</p:properties>
Before we are ready to use EJB in the Apache Camel routes:
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<to uri="ejb:GreaterImplLocal?method=hello"/>
<to uri="mock:result"/>
</route>
</camelContext>
The Esper component supports the Esper Library for Event Stream Processing. The camel-esper library is provided by the Camel Extra project which hosts all *GPL related components for Apache Camel.
esper:name[?options]
When consuming from an Esper endpoint you must specify a pattern or eql statement to query the event stream.
For example
from("esper://cheese?pattern=every event=MyEvent(bar=5)").
to("activemq:Foo");| Name | Default Value | Description |
|---|---|---|
pattern
|
The Esper Pattern expression as a String to filter events | |
eql
|
The Esper EQL expression as a String to filter events |
You can append query options to the URI in the following format,
?option=value&option=value&...
There is a demo which shows how to work with ActiveMQ, Apache Camel and Esper in the Camel Extra project
The event: component provides access to the Spring ApplicationEvent objects. This allows you to publish ApplicationEvent objects to a Spring ApplicationContext or to consume them. You can then use EIPs, like the message filter, to process them.
Available in Apache Camel 2.3
The exec component can be used to execute a system command.
Maven users need to add the following dependency to their pom.xml
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-exec</artifactId>
<version>${camel-version}</version>
</dependency>where ${camel-version} must be replaced by the actual version of Apache Camel
(2.3.0 or higher).
exec://executable[?options]
where executable is the name, or file path, of the system command that
will be executed. If executable name is used (e.g. exec:java), the
executable must in the system path.
| Name | Default value | Description |
|---|---|---|
args
|
null
|
The arguments of the executable. The arguments may be one or many
whitespace-separated tokens, that can be quoted with |
workingDir
|
null
|
The directory in which the command should be executed. If null, the
working directory of the current process will be used. |
timeout
|
Long.MAX_VALUE
|
The timeout, in milliseconds, after which the executable should be terminated. If the executable has has not finished within the timeout, the component will send a termination request. |
outFile
|
null
|
The name of a file, created by the executable, that should be considered as output of
the executable. If no outFile is set, the standard output (stdout) of
the executable will be considered as output. |
binding
|
a DefaultExecBinding instance |
A reference to a org.apache.commons.exec.ExecBinding in the Registry. |
commandExecutor
|
a DefaultCommandExecutor instance |
A reference to a org.apache.commons.exec.ExecCommandExecutor in the
Registry, that customizes
the command execution. The default command executor utilizes the commons-exec library. It adds a
shutdown hook for every executed command. |
useStderrOnEmptyStdout
|
false
|
A boolean which dictates when stdin is empty, it should fallback and
use stderr in the Message Body. This option is default
false. |
The supported headers are defined in
org.apache.camel.component.exec.ExecBinding.
| Name | Type | Message | Description |
|---|---|---|---|
ExecBinding.EXEC_COMMAND_EXECUTABLE
|
String
|
in
|
The name of the system command that will be executed. Overrides the
executable in the URI. |
ExecBinding.EXEC_COMMAND_ARGS
|
java.util.List<String>
|
in
|
The arguments of the executable. The arguments are used literally, no quoting is
applied. Overrides existing args in the URI. |
ExecBinding.EXEC_COMMAND_ARGS
|
String
|
in
|
Camel 2.5: The arguments of the executable as a Single string where each argument is whitespace separated (see args in URI option). The arguments are used literally, no quoting is applied. Overrides existing args in the URI. |
ExecBinding.EXEC_COMMAND_OUT_FILE
|
String
|
in
|
The name of a file, created by the executable, that should be considered as output of
the executable. Overrides existing outFile in the URI. |
ExecBinding.EXEC_COMMAND_TIMEOUT
|
long
|
in
|
The timeout, in milliseconds, after which the executable should be terminated. Overrides
existing timeout in the URI. |
ExecBinding.EXEC_COMMAND_WORKING_DIR
|
String
|
in
|
The directory in which the command should be executed. Overrides existing
workingDir in the URI. |
ExecBinding.EXEC_EXIT_VALUE
|
int
|
out
|
The value of this header is the exit value of the executable. Typically not-zero exit values indicates abnormal termination. Note that the exit value is OS-dependent. |
ExecBinding.EXEC_STDERR
|
java.io.InputStream
|
out
|
The value of this header points to the standard error stream (stderr) of the executable.
If no stderr is written, the value is null. |
ExecBinding.EXEC_USE_STDERR_ON_EMPTY_STDOUT
|
boolean
|
in
|
Indicates when the stdin is empty, should we fallback and use
stderr as the body of the Message. By default this option is
false. |
If the in message body, that that the Exec component
receives, is convertible to java.io.InputStream, it is used to feed input
of the executable via its stdin. After the execution, the message body is the result of the
execution, that is org.apache.camel.components.exec.ExecResult instance
containing the stdout, stderr, exit value and out file. The component supports the following
ExecResult
type converters for
convenience:
| From | To |
|---|---|
ExecResult
|
java.io.InputStream
|
ExecResult
|
String
|
ExecResult
|
byte []
|
ExecResult
|
org.w3c.dom.Document
|
If out file is used (the endpoint is configured with outFile, or there
is ExecBinding.EXEC_COMMAND_OUT_FILE header) the converters return the
content of the out file. If no out file is used, then the converters will use the stdout of
the process for conversion to the target type. For example refer to Usage Examples.
The example below executes wc (word count, Linux) to count the words in
file /usr/share/dict/words. The word count (output) is written in the
standart output stream of wc.
from("direct:exec")
.to("exec:wc?args=--words /usr/share/dict/words")
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
// By default, the body is ExecResult instance
assertIsInstanceOf(ExecResult.class, exchange.getIn().getBody());
// Use the Camel Exec String type converter to convert the ExecResult to String
// In this case, the stdout is considered as output
String wordCountOutput = exchange.getIn().getBody(String.class);
// do something with the word count
}
});The example below executes java with 2 arguments:
-server and -version, provided that
java is in the system path.
from("direct:exec")
.to("exec:java?args=-server -version")The example below executes java in c:/temp with 3
arguments: -server, -version and the sytem property
user.name.
from("direct:exec")
.to("exec:c:/program files/jdk/bin/java?args=-server -version -Duser.name=Camel&workingDir=c:/temp")The following example executes Apache Ant
(Windows only) with the build file CamelExecBuildFile.xml, provided that
ant.bat is in the system path, and that
CamelExecBuildFile.xml is in the current directory.
from("direct:exec")
.to(exec:ant.bat?args=-f CamelExecBuildFile.xml")In the next example, the ant.bat command, redirects the ant output to
CamelExecOutFile.txt with -l. The file
CamelExecOutFile.txt is used as out file with
outFile=CamelExecOutFile.txt. The example assumes that
ant.bat is in the system path, and that
CamelExecBuildFile.xml is in the current directory.
from("direct:exec")
.to("exec:ant.bat?args=-f CamelExecBuildFile.xml -l CamelExecOutFile.txt&outFile=CamelExecOutFile.txt")
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
InputStream outFile = exchange.getIn().getBody(InputStream.class);
assertIsInstanceOf(InputStream.class, outFile);
// do something with the out file here
}
});The FIX component supports the FIX protocol by using the QuickFix/J library.
fix://configurationResource
Where configurationResource points to the QuickFix/J
configuration file to define how to connect to FIX. This could be a resource on the classpath
or a reference to a full URL using the http: or file:
schemes.
By default this component will attempt to use the Type Converter to turn the inbound message body into a QuickFix Message class and all outputs from FIX will be in the same format.
If you are using the Artix Data Services support, then any payload such as files or streams or byte arrays can be converted nicely into FIX messages.
To use this module you need to use the FUSE Mediation Router distribution. Or you could
just add the following to your pom.xml, substituting the version number for
the latest and greatest release:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-parent</artifactId> <version>1.5.3.0-fuse</version> </dependency>
And ensure you are pointing at the maven repo:
<repository>
<id>open.iona.m2</id>
<name>FUSESource Open Source Community Release Repository</name>
<url>http://repo.fusesource.com/maven2/</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>The Flatpack component supports fixed width and delimited file parsing using the FlatPack library. Notice: This component only supports consuming from flatpack files to Object model. You can not (yet) write from Object model to flatpack format.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-flatpack</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
flatpack:[delim|fixed]:flatPackConfig.pzmap.xml[?options]
Or for a delimited file handler with no configuration file just use:
flatpack:someName[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
delimiter
|
,
|
The default character delimiter for delimited files. |
textQualifier
|
"
|
The text qualifier for delimited files. |
ignoreFirstRecord
|
true
|
Whether the first line is ignored for delimited files (for the column headers). |
splitRows
|
true
|
As of Apache Camel 1.5, the component can either process each row one by one or the entire content at once. |
flatpack:fixed:foo.pzmap.xml creates a fixed-width endpoint using
the foo.pzmap.xml file configuration.
flatpack:delim:bar.pzmap.xml creates a delimited endpoint using the
bar.pzmap.xml file configuration.
flatpack:foo creates a delimited endpoint called
foo with no file configuration.
Apache Camel will store the following headers on the IN message:
| Header | Description |
|---|---|
camelFlatpackCounter
|
The current row index. For splitRows=false the counter is the total
number of rows. |
The component delivers the data in the IN message as a
org.apache.camel.component.flatpack.DataSetList object that has
converters for java.util.Map or java.util.List. Usually
you want the Map if you process one row at a time
(splitRows=true). Use List for the entire content
(splitRows=false), where each element in the list is a
Map. Each Map contains the key for the column name and
its corresponding value.
For example to get the firstname from the sample below:
Map row = exchange.getIn().getBody(Map.class);
String firstName = row.get("FIRSTNAME");However, you can also always get it as a List (even for
splitRows=true). The same example:
List data = exchange.getIn().getBody(List.class);
Map row = (Map)data.get(0);
String firstName = row.get("FIRSTNAME");In Apache Camel 1.5 onwards the header and trailer notions in Flatpack are supported. However, you must use fixed record IDs:
header for the header record (must be lowercase)
trailer for the trailer record (must be lowercase)
The example below illustrates this fact that we have a header and a trailer. You can omit one or both of them if not needed.
<RECORD id="header" startPosition="1" endPosition="3" indicator="HBT">
<COLUMN name="INDICATOR" length="3"/>
<COLUMN name="DATE" length="8"/>
</RECORD>
<COLUMN name="FIRSTNAME" length="35" />
<COLUMN name="LASTNAME" length="35" />
<COLUMN name="ADDRESS" length="100" />
<COLUMN name="CITY" length="100" />
<COLUMN name="STATE" length="2" />
<COLUMN name="ZIP" length="5" />
<RECORD id="trailer" startPosition="1" endPosition="3" indicator="FBT">
<COLUMN name="INDICATOR" length="3"/>
<COLUMN name="STATUS" length="7"/>
</RECORD>A common use case is sending a file to this endpoint for further processing in a separate route. For example:
<camelContext xmlns="http://activemq.apache.org/camel/schema/spring">
<route>
<from uri="file://someDirectory"/>
<to uri="flatpack:foo"/>
</route>
<route>
<from uri="flatpack:foo"/>
...
</route>
</camelContext>You can also convert the payload of each message created to a Map for
easy Bean Integration
Available as of Apache Camel 1.6
The freemarker: component allows you to process a message using a Freemarker template. This can be ideal when using Templating to generate responses for requests.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-freemarker</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
freemarker:templateName[?options]
Where templateName is the classpath-local URI of the
template to invoke; or the complete URL of the remote template (for example,
file://folder/myfile.ftl).
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default | Description |
|---|---|---|
contentCache
|
true
|
Cache for the resource content when its loaded. |
encoding
|
null
|
Character encoding of the resource content. |
Apache Camel will store a reference to the resource in the message header in the key
org.apache.camel.freemarker.resource. The Resource is an
org.springframework.core.io.Resource object. And the key
org.apache.camel.freemarker.resourceUri holds the templateName as a String
| Note |
|---|---|
From Camel 2.1 and Camel 1.6.2, freemarker endpoint will not store these headers into to message, as these header will cause some side effect on the dynamic templates feature. |
Headers set during the Freemarker evaluation are returned to the message and added as headers. This makes it possible to return values from Freemarker to the Message.
For example, to set the header value of fruit in the Freemarker
template:
${request.setHeader('fruit', 'Apple')}The header, fruit, is now accessible from the
message.out.headers.
Apache Camel will provide exchange information in the Freemarker context (just a
Map). The Exchange is transfered as:
| Key | Value |
|---|---|
exchange
|
The Exchange itself. |
headers
|
The headers of the In message. |
camelContext
|
The Camel Context. |
request
|
The In message. |
body
|
The In message body. |
response
|
The Out message (only for InOut message exchange pattern). |
The Freemarker template resource is by default not
hot reloadable for both file and classpath resources (expanded jar). If you set
contentCache=false, then Apache Camel will not cache the resource and
hot reloading is thus enabled. This scenario can be used in development.
Available as of Camel 2.1 Camel provides two headers by which you can define a different resource location for a template or the template content itself. If any of these headers is set then Camel uses this over the endpoint configured resource. This allows you to provide a dynamic template at runtime.
| Header | Type | Description |
|---|---|---|
| CamelFreemarkerResourceUri | String | Camel 2.1: A URI for the template resource to use instead of the endpoint configured. |
| CamelFreemarkerTemplate | String | Camel 2.1: The template to use instead of the endpoint configured. |
For example, you can define a route like the following:
from("activemq:My.Queue").
to("freemarker:com/acme/MyResponse.ftl");To use a Freemarker template to formulate a response to InOut
message exchanges (where there is a JMSReplyTo header).
If you want to process InOnly exchanges, you could use a Freemarker template to transform the message before sending it on to another endpoint:
from("activemq:My.Queue").
to(ExchangePattern.InOut,"freemarker:com/acme/MyResponse.ftl").
to("activemq:Another.Queue");And to disable the content cache (for example, for development usage where the
.ftl template should be hot reloaded):
from("activemq:My.Queue").
to(ExchangePattern.InOut,"freemarker:com/acme/MyResponse.ftl?contentCache=false").
to("activemq:Another.Queue");And for a file-based resource:
from("activemq:My.Queue").
to(ExchangePattern.InOut,"freemarker:file://myfolder/MyResponse.ftl?contentCache=false").
to("activemq:Another.Queue");In Camel 2.1 it's possible to specify what template the component should use dynamically via a header, so for example:
from("direct:in").
setHeader("CamelFreemarkerResourceUri").constant("path/to/my/template.ftl").
to("freemarker:dummy");
In this sample we want to use Freemarker templating for an order confirmation email. The email template is laid out in Freemarker as:
Dear ${headers.lastName}, ${headers.firstName}
Thanks for the order of ${headers.item}.
Regards Camel Riders Bookstore
${body}And the java code:
private Exchange createLetter() {
Exchange exchange = context.getEndpoint("direct:a").createExchange();
Message msg = exchange.getIn();
msg.setHeader("firstName", "Claus");
msg.setHeader("lastName", "Ibsen");
msg.setHeader("item", "Camel in Action");
msg.setBody("PS: Next beer is on me, James");
return exchange;
}
@Test
public void testFreemarkerLetter() throws Exception {
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedMessageCount(1);
mock.expectedBodiesReceived("Dear Ibsen, Claus\n\nThanks for the order of Camel in Action.\n\nRegards Camel Riders Bookstore\nPS: Next beer is on me, James");
template.send("direct:a", createLetter());
mock.assertIsSatisfied();
}
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
public void configure() throws Exception {
from("direct:a").to("freemarker:org/apache/camel/component/freemarker/letter.ftl").to("mock:result");
}
};
}
Available as of Camel 2.7
The hazelcast: component allows you to work with the Hazelcast distributed data grid / cache. Hazelcast is a in memory data grid, entirely written in Java (single jar). It offers a great palette of different data stores like map, multi map (same key, n values), queue, list and atomic number. The main reason to use Hazelcast is its simple cluster support. If you have enabled multicast on your network you can run a cluster with hundred nodes with no extra configuration. Hazelcast can simply configured to add additional features like n copies between nodes (default is 1), cache persistence, network configuration (if needed), near cache, enviction and so on. For more information consult the Hazelcast documentation on http://www.hazelcast.com/documentation.jsp .
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-hazelcast</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
hazelcast:[ map | multimap | queue | seda | set | atomicvalue | instance]:cachename[?options]
| Warning |
|---|---|
You have to use the second prefix to define which type of data store you want to use. |
If you want to store a value in a map you can use the map cache producer. The map cache producer provides 5 operations (put, get, update, delete, query). For the first 4 you have to provide the operation inside the "hazelcast.operation.type" header variable. In Java DSL you can use the constants from org.apache.camel.component.hazelcast.HazelcastConstants.
Header Variables for the request message:
| Name | Type | Description |
|---|---|---|
hazelcast.operation.type
|
String
|
valid values are: put, delete, get, update, query |
hazelcast.objectId
|
String
|
the object id to store / find your object inside the cache (not needed for the query operation) |
You can call the samples with:
template.sendBodyAndHeader("direct:[put|get|update|delete|query]", "my-foo", HazelcastConstants.OBJECT_ID, "4711");
<route> <from uri="direct:put" /> <setHeader headerName="hazelcast.operation.type"> <constant>put</constant> </setHeader> <to uri="hazelcast:map:foo" /> </route>
<route> <from uri="direct:get" /> <setHeader headerName="hazelcast.operation.type"> <constant>get</constant> </setHeader> <to uri="hazelcast:map:foo" /> <to uri="seda:out" /> </route>
<route> <from uri="direct:update" /> <setHeader headerName="hazelcast.operation.type"> <constant>update</constant> </setHeader> <to uri="hazelcast:map:foo" /> </route>
<route> <from uri="direct:delete" /> <setHeader headerName="hazelcast.operation.type"> <constant>delete</constant> </setHeader> <to uri="hazelcast:map:foo" /> </route>
<route> <from uri="direct:query" /> <setHeader headerName="hazelcast.operation.type"> <constant>query</constant> </setHeader> <to uri="hazelcast:map:foo" /> <to uri="seda:out" /> </route>
For the query operation Hazelcast offers a SQL like syntax to query your distributed map.
String q1 = "bar > 1000";
template.sendBodyAndHeader("direct:query", null, HazelcastConstants.QUERY, q1);
Hazelcast provides event listeners on their data grid. If you want to be notified if a cache will be manipulated, you can use the map consumer. There're 4 events: put, update, delete and envict. The event type will be stored in the "hazelcast.listener.action" header variable. The map consumer provides some additional information inside these variables:
Header Variables inside the response message:
| Name | Type | Description |
|---|---|---|
hazelcast.listener.time
|
Long
|
time of the event in millis |
hazelcast.listener.type
|
String
|
the map consumer sets here "cachelistener" |
hazelcast.listener.action
|
String
|
type of event - here added, updated, envicted and removed |
hazelcast.objectId
|
String
|
the oid of the object |
hazelcast.cache.name
|
String
|
the name of the cache - e.g. "foo" |
hazelcast.cache.type
|
String
|
the type of the cache - here map |
The object value will be stored within put and update actions inside the message body.
Here's a sample:
fromF("hazelcast:%sfoo", HazelcastConstants.MAP_PREFIX)
.log("object...")
.choice()
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ADDED))
.log("...added")
.to("mock:added")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ENVICTED))
.log("...envicted")
.to("mock:envicted")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.UPDATED))
.log("...updated")
.to("mock:updated")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.REMOVED))
.log("...removed")
.to("mock:removed")
.otherwise()
.log("fail!");
A multimap is a cache where you can store n values to one key. The multimap producer provides 4 operations (put, get, removevalue, delete).
Header Variables for the request message:
| Name | Type | Description |
|---|---|---|
hazelcast.operation.type
|
String
|
valid values are: put, get, removevalue, delete |
hazelcast.objectId
|
String
|
the object id to store / find your object inside the cache |
<route> <from uri="direct:put" /> <log message="put.."/> <setHeader headerName="hazelcast.operation.type"> <constant>put</constant> </setHeader> <to uri="hazelcast:multimap:foo" /> </route>
<route> <from uri="direct:removevalue" /> <log message="removevalue..."/> <setHeader headerName="hazelcast.operation.type"> <constant>removevalue</constant> </setHeader> <to uri="hazelcast:multimap:foo" /> </route>
To remove a value you have to provide the value you want to remove inside the message body. If you have a multimap object
} you have to put "my-foo" inside the message body to remove the "my-foo" value.
<route> <from uri="direct:get" /> <log message="get.."/> <setHeader headerName="hazelcast.operation.type"> <constant>get</constant> </setHeader> <to uri="hazelcast:multimap:foo" /> <to uri="seda:out" /> </route>
<route> <from uri="direct:delete" /> <log message="delete.."/> <setHeader headerName="hazelcast.operation.type"> <constant>delete</constant> </setHeader> <to uri="hazelcast:multimap:foo" /> </route>
you can call them in your test class with:
template.sendBodyAndHeader("direct:[put|get|removevalue|delete]", "my-foo", HazelcastConstants.OBJECT_ID, "4711");
For the multimap cache this component provides the same listeners / variables as for the map cache consumer (except the update and enviction listener). The only difference is the multimap prefix inside the URI. Here is a sample:
fromF("hazelcast:%sbar", HazelcastConstants.MULTIMAP_PREFIX)
.log("object...")
.choice()
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ADDED))
.log("...added")
.to("mock:added")
//.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ENVICTED))
// .log("...envicted")
// .to("mock:envicted")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.REMOVED))
.log("...removed")
.to("mock:removed")
.otherwise()
.log("fail!");
Header Variables inside the response message:
| Name | Type | Description |
|---|---|---|
hazelcast.listener.time
|
Long
|
time of the event in millis |
hazelcast.listener.type
|
String
|
the map consumer sets here "cachelistener" |
hazelcast.listener.action
|
String
|
type of event - here added and removed (and soon envicted) |
hazelcast.objectId
|
String
|
the oid of the object |
hazelcast.cache.name
|
String
|
the name of the cache - e.g. "foo" |
hazelcast.cache.type
|
String
|
the type of the cache - here multimap |
Enviction will be added as feature, soon (this is a Hazelcast issue).
The queue producer provides 6 operations (add, put, poll, peek, offer, removevalue).
from("direct:add")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.ADD_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
from("direct:put")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.PUT_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
from("direct:poll")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.POLL_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
from("direct:peek")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.PEEK_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
from("direct:offer")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.OFFER_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
from("direct:removevalue")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.REMOVEVALUE_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.QUEUE_PREFIX);
The queue consumer provides 2 operations (add, remove).
fromF("hazelcast:%smm", HazelcastConstants.QUEUE_PREFIX)
.log("object...")
.choice()
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ADDED))
.log("...added")
.to("mock:added")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.REMOVED))
.log("...removed")
.to("mock:removed")
.otherwise()
.log("fail!");
The list producer provides 4 operations (add, set, get, removevalue).
from("direct:add")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.ADD_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.LIST_PREFIX);
from("direct:get")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.GET_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.LIST_PREFIX)
.to("seda:out");
from("direct:set")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.SETVALUE_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.LIST_PREFIX);
from("direct:removevalue")
.setHeader(HazelcastConstants.OPERATION, constant(HazelcastConstants.REMOVEVALUE_OPERATION))
.toF("hazelcast:%sbar", HazelcastConstants.LIST_PREFIX);
| Warning |
|---|---|
Please note that set,get and removevalue and not yet supported by hazelcast, will be added in the future.. |
The list consumer provides 2 operations (add, remove).
fromF("hazelcast:%smm", HazelcastConstants.LIST_PREFIX)
.log("object...")
.choice()
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ADDED))
.log("...added")
.to("mock:added")
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.REMOVED))
.log("...removed")
.to("mock:removed")
.otherwise()
.log("fail!");
SEDA component differs from the rest components provided. It implements a work-queue in order to support asynchronous SEDA architectures, similar to the core "SEDA" component.
The SEDA producer provides no operations. You only send data to the specified queue.
Spring DSL :
<route> <from uri="direct:start" /> <to uri="hazelcast:seda:foo" /> </route>
The SEDA consumer provides no operations. You only retrieve data from the specified queue.
<route> <from uri="hazelcast:seda:foo" /> <to uri="mock:result" /> </route>
An atomic number is an object that simply provides a grid wide number (long). The operations for this producer are setvalue (set the number with a given value), get, increase (+1), decrease (-1) and destroy.
Header Variables for the request message:
| Name | Type | Description |
|---|---|---|
hazelcast.operation.type
|
String
|
valid values are: setvalue, get, increase, decrease, destroy |
<route> <from uri="direct:set" /> <setHeader headerName="hazelcast.operation.type"> <constant>setvalue</constant> </setHeader> <to uri="hazelcast:atomicvalue:foo" /> </route>
Provide the value to set inside the message body (here the value is 10): template.sendBody("direct:set", 10);
<route> <from uri="direct:get" /> <setHeader headerName="hazelcast.operation.type"> <constant>get</constant> </setHeader> <to uri="hazelcast:atomicvalue:foo" /> </route>
You can get the number with long body = template.requestBody("direct:get", null, Long.class);.
<route> <from uri="direct:increment" /> <setHeader headerName="hazelcast.operation.type"> <constant>increment</constant> </setHeader> <to uri="hazelcast:atomicvalue:foo" /> </route>
The actual value (after increment) will be provided inside the message body.
<route> <from uri="direct:decrement" /> <setHeader headerName="hazelcast.operation.type"> <constant>decrement</constant> </setHeader> <to uri="hazelcast:atomicvalue:foo" /> </route>
The actual value (after decrement) will be provided inside the message body.
| Warning |
|---|---|
There's a bug inside Hazelcast. So this feature may not work properly. Will be fixed in 1.9.3. |
<route> <from uri="direct:destroy" /> <setHeader headerName="hazelcast.operation.type"> <constant>destroy</constant> </setHeader> <to uri="hazelcast:atomicvalue:foo" /> </route>
Hazelcast makes sense in one single "server node", but it's extremly powerful in a clustered environment. The instance consumer fires if a new cache instance will join or leave the cluster.
Here's a sample:
fromF("hazelcast:%sfoo", HazelcastConstants.INSTANCE_PREFIX)
.log("instance...")
.choice()
.when(header(HazelcastConstants.LISTENER_ACTION).isEqualTo(HazelcastConstants.ADDED))
.log("...added")
.to("mock:added")
.otherwise()
.log("...removed")
.to("mock:removed");
Each event provides the following information inside the message header:
Header Variables inside the response message:
| Name | Type | Description |
|---|---|---|
hazelcast.listener.time
|
Long
|
time of the event in millis |
hazelcast.listener.type
|
String
|
the map consumer sets here "instancelistener" |
hazelcast.listener.action
|
String
|
type of event - here added or removed |
hazelcast.instance.host
|
String
|
host name of the instance |
hazelcast.instance.port
|
Integer
|
port number of the instance |
The hibernate: component allows you to work with databases using Hibernate as the object relational mapping technology to map POJOs to database tables. The camel-hibernate library is provided by the Camel Extra project which hosts all GPL related components for Apache Camel.
Sending POJOs to the hibernate endpoint inserts entities into the database. The body
of the message is assumed to be an entity bean that you have mapped to a relational
table using the hibernate .hbm.xml files.
If the body does not contain an entity bean, 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; consumers 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.
hibernate:[entityClassName][?options]
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.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
entityType
|
entityClassName | Is the provided entityClassName from the URI. |
consumeDelete
|
true
|
Option for HibernateConsumer only. Specifies whether or not the entity is deleted after it is consumed. |
consumeLockEntity
|
true
|
Option for HibernateConsumer only. Specifies whether or not to use exclusive locking of each entity while processing the results from the pooling. |
flushOnSend
|
true
|
Option for HibernateProducer only. Flushes the EntityManager after the entity bean has been persisted. |
maximumResults
|
-1
|
Option for HibernateConsumer only. Set the maximum number of results to retrieve on the Query. |
consumer.delay
|
500
|
Option for HibernateConsumer only. Delay in millis between each poll. |
consumer.initialDelay
|
1000
|
Option for HibernateConsumer only. Millis before polling starts. |
consumer.userFixedDelay
|
false
|
Option for HibernateConsumer only. Set to true to use fixed
delay between polls, otherwise fixed rate is used. See ScheduledExecutorService in JDK for details. |
The ibatis: component allows you to query, poll, insert, update and delete data in a relational database using Apache iBATIS.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-ibatis</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
ibatis:statementName[?options]
Where statementName is the name in the iBATIS XML configuration file which maps to the query, insert, update or delete operation you wish to evaluate.
You can append query options to the URI in the following format,
?option=value&option=value&...
This component will by default load the iBatis SqlMapConfig file from the root of the classpath and expected named as SqlMapConfig.xml.
It uses Spring resource loading so you can define it using classpath, file or http as prefix to load resources with those schemes.
In Camel 2.2 you can configure this on the iBatisComponent with the setSqlMapConfig(String) method.
| Option | Type | Default | Description |
|---|---|---|---|
consumer.onConsume
|
String
|
null
|
Statements to run after consuming. Can be used, for example, to update rows after they have been consumed and processed in Apache Camel. See sample later. Multiple statements can be separated with comma. |
consumer.useIterator
|
boolean
|
true
|
If true each row returned when polling will be processed
individually. If false the entire List of data is
set as the IN body. |
consumer.routeEmptyResultSet
|
boolean
|
false
|
Apache Camel 2.0: Sets whether empty result set should be routed or not. By default, empty result sets are not routed. |
statementType
|
StatementType
|
null
|
Apache Camel 1.6.1/2.0: Mandatory to specify for
IbatisProducer to control which iBatis SqlMapClient method to invoke.
The enum values are: QueryForObject, QueryForList,
Insert, Update, Delete. |
maxMessagesPerPoll
|
int
|
0
|
Apache Camel 2.0: An integer to define a maximum messages to gather per poll. By default, no maximum is set. Can be used to set a limit of e.g. 1000 to avoid when starting up the server that there are thousands of files. Set a value of 0 or negative to disabled it. |
Apache Camel will populate the result message, either IN or OUT with a header with the operationName used:
| Header | Type | Description |
|---|---|---|
org.apache.camel.ibatis.queryName
|
String
|
Apache Camel 1.x: The statementName used (for example: insertAccount). |
CamelIBatisStatementName
|
String
|
Apache Camel 2.0: The statementName used (for example: insertAccount). |
CamelIBatisResult
|
Object
|
Apache Camel 1.6.2/2.0: The response returned from iBatis
in any of the operations. For instance an INSERT could return the
auto-generated key, or number of rows etc. |
Apache Camel 1.6.1: The response from iBatis will be set as OUT body.
Apache Camel 1.6.2/2.0: The response from
iBatis will only be set as body if it's a SELECT statement. That means, for
example, for INSERT statements Apache Camel will not replace the body. This
allows you to continue routing and keep the original body. The response from iBatis is always
stored in the header with the key CamelIBatisResult.
For example if you wish to consume beans from a JMS queue and insert them into a database you could do the following:
from("activemq:queue:newAccount").
to("ibatis:insertAccount?statementType=Insert");Notice we have to specify the statementType, as we need to instruct
Apache Camel which SqlMapClient operation to invoke.
Where insertAccount is the iBatis ID in the SQL map file:
<!-- Insert example, using the Account parameter class -->
<insert id="insertAccount" parameterClass="Account">
insert into ACCOUNT (
ACC_ID,
ACC_FIRST_NAME,
ACC_LAST_NAME,
ACC_EMAIL
)
values (
#id#, #firstName#, #lastName#, #emailAddress#
)
</insert>Available as of Apache Camel 1.6.1/2.0 When routing to an
iBatis endpoint you want more fine grained control so you can control whether the SQL
statement to be executed is a SELEECT, UPDATE,
DELETE or INSERT etc. This is now possible in Apache Camel
1.6.1/2.0. So for instance if we want to route to an iBatis endpoint in which the IN body
contains parameters to a SELECT statement we can do:
from("direct:start")
.to("ibatis:selectAccountById?statementType=QueryForObject")
.to("mock:result");
In the code above we can invoke the iBatis statement selectAccountById
and the IN body should contain the account id we want to retrieve, such as an
Integer type.
We can do the same for some of the other operations, such as
QueryForList:
from("direct:start")
.to("ibatis:selectAllAccounts?statementType=QueryForList")
.to("mock:result");
And the same for UPDATE, where we can send an
Account object as IN body to iBatis:
from("direct:start")
.to("ibatis:updateAccount?statementType=Update")
.to("mock:result");
Since this component does not support scheduled polling, you need to use another mechanism for triggering the scheduled polls, such as the Timer or Quartz components.
In the sample below we poll the database, every 30 seconds using the Timer component and send the data to the JMS queue:
from("timer://pollTheDatabase?delay=30000").to("ibatis:selectAllAccounts?statementType=QueryForList").to("activemq:queue:allAccounts");And the iBatis SQL map file used:
<!-- Select with no parameters using the result map for Account class. -->
<select id="selectAllAccounts" resultMap="AccountResult">
select * from ACCOUNT
</select>This component supports executing statements after data
have been consumed and processed by Apache Camel. This allows you to do post updates in the
database. Notice all statements must be UPDATE statements. Apache Camel
supports executing multiple statements whose name should be separated by comma.
The route below illustrates we execute the consumeAccount statement data is processed. This allows us to change the status of the row in the database to processed, so we avoid consuming it twice or more.
from("ibatis:selectUnprocessedAccounts?consumer.onConsume=consumeAccount").to("mock:results");And the statements in the sqlmap file:
<select id="selectUnprocessedAccounts" resultMap="AccountResult">
select * from ACCOUNT where PROCESSED = false
</select><update id="consumeAccount" parameterClass="Account">
update ACCOUNT set PROCESSED = true where ACC_ID = #id#
</update>
The javaspace component is a transport for working with
any JavaSpace compliant implementation and this component has been tested with both the Blitz implementation and the GigaSpace implementation. This component can be
used for sending and receiving any object inheriting from the Jini
net.jini.core.entry.Entry class. It is also possible to pass the bean ID
of a template that can be used for reading/taking the entries from the space. This component
can be used for sending/receiving any serializable object acting as a sort of generic
transport. The JavaSpace component contains a special optimization for dealing with the
BeanExchange. It can be used to invoke a POJO remotely, using a JavaSpace
as a transport. This latter feature can provide a simple implementation of the master/worker
pattern, where a POJO provides the business logic for the worker. Look at the test cases for
examples of various use cases for this component.
javaspace:jini://host[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
spaceName
|
null
|
Specifies the JavaSpace name. |
verb
|
take
|
Specifies the verb for getting JavaSpace entries. The values can be:
take or read. |
transactional
|
false
|
If true, sending and receiving entries is performed within a
transaction. |
transactionalTimeout
|
Long.MAX_VALUE
|
Specifies the transaction timeout. |
concurrentConsumers
|
1
|
Specifies the number of concurrent consumers getting entries from the JavaSpace. |
templateId
|
null
|
If present, this option specifies the Spring bean ID of the template to use for reading/taking entries. |
//Sending route
from("direct:input").to("javaspace:jini://localhost?spaceName=mySpace");
//Receiving Route
from("javaspace:jini://localhost?spaceName=mySpace&templateId=template&verb=take&concurrentConsumers=1")In this case the payload can be any object that inherits from the Jini
Entry type.
Using the preceding routes, it is also possible to send and receive any serializable
object. The JavaSpace component detects that the payload is not a Jini
Entry and then it automatically wraps the payload with a Camel Jini
Entry. In this way, a JavaSpace can be used as a generic transport
mechanism.
The JavaSpace component has been tailored to work in combination with the Camel bean component. It is therefore possible to call a remote POJO using JavaSpace as the transport:
from("direct:input").to("javaspace:jini://localhost?spaceName=mySpace"); //Client side
from("javaspace:jini://localhost?concurrentConsumers=10&spaceName=mySpace").to("pojo:pojo"); //Server side
In the code there are two test cases showing how to use a POJO to realize the master/worker pattern. The idea is to use the POJO to provide the business logic and rely on Apache Camel for sending/receiving requests/replies with the proper correlation.
To use this module, you need the FUSE Mediation Router
distribution. Or you can just add the following dependency to your pom.xml
file, substituting the version number of the latest release:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-parent</artifactId> <version>1.6.1.2-fuse</version> </dependency>
Make sure that you are pointing at the right Maven repository:
<repository>
<id>fuse</id>
<name>Progress Open Source Community Release Repository</name>
<url>http://repo.fusesource.com/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>The source for camel-javaspace is available at: http://fusesource.com/forge/svn/fuseeip/trunk/components/camel-javaspace/
You need to register with http://fusesource.com to be able to access subversion.
The full FUSE distro is available from: http://fusesource.com/products/enterprise-camel/
The jbi component is implemented by the ServiceMix Camel module and provides integration with a JBI Normalized Message Router, such as the one provided by Apache ServiceMix.
| Important |
|---|---|
See below for information about how to use |
The following code:
from("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint")Automatically exposes a new endpoint to the bus, where the service QName is
{http://foo.bar.org}MyService and the endpoint name is
MyEndpoint (see URI format).
When a JBI endpoint appears at the end of a route, for example:
to("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint")The messages sent by this producer endpoint are sent to the already deployed JBI endpoint.
jbi:service:serviceNamespace[sep]serviceName[?options] jbi:endpoint:serviceNamespace[sep]serviceName[sep]endpointName[?options] jbi:name:endpointName[?options]
The separator that should be used in the endpoint URL is:
/ (forward slash), if serviceNamespace starts
with http://, or
: (colon), if serviceNamespace starts with
urn:foo:bar.
For more details of valid JBI URIs see the ServiceMix URI Guide.
Using the jbi:service: or jbi:endpoint: URI formats
sets the service QName on the JBI endpoint to the one specified. Otherwise, the default
Apache Camel JBI Service QName is used, which is:
{http://activemq.apache.org/camel/schema/jbi}endpointYou can append query options to the URI in the following format,
?option=value&option=value&...
jbi:service:http://foo.bar.org/MyService jbi:endpoint:urn:foo:bar:MyService:MyEndpoint jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint jbi:name:cheese
| Name | Default value | Description |
|---|---|---|
mep
|
MEP of the Camel Exchange | Allows users to override the MEP set on the Exchange object. Valid values for this
option are in-only, in-out,
robust-in-out and in-optional-out. |
operation
|
Value of the jbi.operation header property |
Specifies the JBI operation for the MessageExchange. If no value is
supplied, the JBI binding will use the value of the jbi.operation
header property. |
serialization
|
basic
|
Default value (basic) will check if headers are serializable by looking at the type, setting this option to strict will detect objects that can not be serialized although they implement the Serializable interface. Set to nocheck to disable this check altogether, note that this should only be used for in-memory transports like SEDAFlow, otherwise you can expect to get NotSerializableException thrown at runtime. |
convertException
|
false
|
false: send any exceptions thrown from the Camel route back unmodified
true: convert all exceptions to a JBI FaultException (can be used to avoid non-serializable exceptions or to implement generic error handling |
jbi:service:http://foo.bar.org/MyService?mep=in-out (override the MEP, use InOut JBI MessageExchanges)
jbi:endpoint:urn:foo:bar:MyService:MyEndpoint?mep=in (override the MEP, use InOnly JBI MessageExchanges)
jbi:endpoint:urn:foo:bar:MyService:MyEndpoint?operation={http://www.mycompany.org}AddNumbers (overide the operation for the JBI Exchange to {http://www.mycompany.org}AddNumbers)If you are using a stream type as the message body, you should be aware that a stream is
only capable of being read once. So if you enable DEBUG logging, the body
is usually logged and thus read. To deal with this, Apache Camel has a
streamCaching option that can cache the stream, enabling you to read it
multiple times.
from("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint").streamCaching().to("xslt:transform.xsl", "bean:doSomething");From Apache Camel 1.5 onwards, the stream
caching is default enabled, so it is not necessary to set the
streamCaching() option.
In Apache Camel 2.0 we store big input
streams (by default, over 64K) in a temp file using
CachedOutputStream. When you close the input stream, the temp file will
be deleted.
If you have some Apache Camel routes that you want to deploy inside JBI as a Service Unit, you can use the JBI Service Unit Archetype to create a new Maven project for the Service Unit.
If you have an existing Maven project that you need to convert into a JBI Service Unit, you may want to consult ServiceMix Maven JBI Plugins for further help. The key steps are as follows:
Create a Spring XML file at src/main/resources/camel-context.xml to
bootstrap your routes inside the JBI Service Unit.
Change the POM file's packaging to jbi-service-unit.
Your pom.xml should look something like this to enable the
jbi-service-unit packaging:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>myGroupId</groupId>
<artifactId>myArtifactId</artifactId>
<packaging>jbi-service-unit</packaging>
<version>1.0-SNAPSHOT</version>
<name>A Apache Camel based JBI Service Unit</name>
<url>http://www.myorganization.org</url>
<properties>
<camel-version>1.0.0</camel-version>
<servicemix-version>3.3</servicemix-version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.servicemix</groupId>
<artifactId>servicemix-camel</artifactId>
<version>${servicemix-version}</version>
</dependency>
<dependency>
<groupId>org.apache.servicemix</groupId>
<artifactId>servicemix-core</artifactId>
<version>${servicemix-version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<defaultGoal>install</defaultGoal>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
<!-- creates the JBI deployment unit -->
<plugin>
<groupId>org.apache.servicemix.tooling</groupId>
<artifactId>jbi-maven-plugin</artifactId>
<version>${servicemix-version}</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
</project>For more information, see the following references:
If you want to spin up your own project to use Apache Camel to perform some smart routing inside your JBI based ESB you can use the Maven archtetype to get up to speed quickly.
Just type the following into a console...
mvn archetype:create \ -DarchetypeGroupId=org.apache.camel \ -DarchetypeArtifactId=camel-jbi-service-unit \ -DarchetypeVersion=1.0-SNAPSHOT \ -DgroupId=myGroupId \ -DartifactId=myArtifactId
This will create a maven project which can be run immediately via the Camel Maven Plugin as follows
cd myArtifactId mvn install
The configuration file is in src/main/resources/camel-context.xml.
The routing rules lives at src/main/java/myGroupId/MyRouteBuilder.java.
The jcr component allows you to
add nodes to a JCR (JSR-170) compliant content repository (for example, Apache Jackrabbit).
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jcr</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
The repository element of the URI is used to look up the JCR
Repository object in the Camel context registry.
If a message is sent to a JCR producer endpoint:
A new node is created in the content repository,
All the message properties of the IN message are transformed to JCR
Value instances and added to the new node,
The node's UUID is returned in the OUT message.
All message properties are converted to node properties, except for the
CamelJcrNodeName property (you can refer to
JcrConstants.NODE_NAME in your code), which is used to determine
the node name.
The snippet below creates a node named node under the
/home/test node in the content repository. One additional
attribute is added to the node as well: my.contents.property which
will contain the body of the message being sent.
from("direct:a").setProperty(JcrConstants.JCR_NODE_NAME, constant("node"))
.setProperty("my.contents.property", body()).to("jcr://user:pass@repository/home/test");
The jdbc component enables you to access databases through JDBC, where SQL queries and operations are sent in the message body. This component uses the standard JDBC API, unlike the SQL Component component, which uses spring-jdbc.
| Warning |
|---|---|
This component can only be used to define producer endpoints, which means that you
cannot use the JDBC component in a |
jdbc:dataSourceName[?options]
This component only supports producer endpoints.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
readSize
|
0 / 2000
|
The default maximum number of rows that can be read by a polling query. The default value is 2000 for Apache Camel 1.5.0 or older. In newer releases the default value is 0. |
statement.<xxx>
|
null
|
Apache Camel 2.1: Sets additional options on the
java.sql.Statement that is used behind the scenes to execute the
queries. For instance, statement.maxRows=10. For detailed
documentation, see the java.sql.Statement javadoc documentation. |
useJDBC4ColumnNameAndLabelSemantics
|
true
|
Apache Camel 1.6.3/2.2: Sets whether to use JDBC 4/3 column
label/name semantics. You can use this option to turn it false in case
you have issues with your JDBC driver to select data. This only applies when using
SQL SELECT using aliases (e.g. SQL SELECT id as identifier,
name as given_name from persons). |
The result is returned in the OUT body as an ArrayList<HashMap<String,
Object>>. The List object contains the list of rows and the
Map objects contain each row with the String key as
the column name.
| Note |
|---|---|
This component fetches |
| Header | Description |
|---|---|
CamelJdbcRowCount
|
If the query is a SELECT, the row count is returned in this OUT
header. |
CamelJdbcUpdateCount
|
If the query is an UPDATE, the update count is returned in this OUT
header. |
In the following example, we fetch the rows from the customer table.
First we register our datasource in the Apache Camel registry as
testdb:
JndiRegistry reg = super.createRegistry();
reg.bind("testdb", ds);
return reg;Then we configure a route that routes to the JDBC component, so the SQL will be executed.
Note how we refer to the testdb datasource that was bound in the previous
step:
// lets add simple route
public void configure() throws Exception {
from("direct:hello").to("jdbc:testdb?readSize=100");
}Or you can create a DataSource in Spring like this:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="timer://kickoff?period=10000"/>
<setBody>
<constant>select * from customer</constant>
</setBody>
<to uri="jdbc:testdb"/>
<to uri="mock:result"/>
</route>
</camelContext>
<!-- Just add a demo to show how to bind a date source for camel in Spring-->
<bean id="testdb" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
<property name="url" value="jdbc:hsqldb:mem:camel_jdbc" />
<property name="username" value="sa" />
<property name="password" value="" />
</bean> We create an endpoint, add the SQL query to the body of the IN message, and then send the exchange. The result of the query is returned in the OUT body:
// first we create our exchange using the endpoint
Endpoint endpoint = context.getEndpoint("direct:hello");
Exchange exchange = endpoint.createExchange();
// then we set the SQL on the in body
exchange.getIn().setBody("select * from customer order by ID");
// now we send the exchange to the endpoint, and receives the response from Camel
Exchange out = template.send(endpoint, exchange);
// assertions of the response
assertNotNull(out);
assertNotNull(out.getOut());
ArrayList<HashMap<String, Object>> data = out.getOut().getBody(ArrayList.class);
assertNotNull("out body could not be converted to an ArrayList - was: "
+ out.getOut().getBody(), data);
assertEquals(2, data.size());
HashMap<String, Object> row = data.get(0);
assertEquals("cust1", row.get("ID"));
assertEquals("jstrachan", row.get("NAME"));
row = data.get(1);
assertEquals("cust2", row.get("ID"));
assertEquals("nsandhu", row.get("NAME"));
If you want to work on the rows one by one instead of the entire ResultSet at once you need to use the Splitter EIP such as:
from("direct:hello")
// here we split the data from the testdb into new messages one by one
// so the mock endpoint will receive a message per row in the table
.to("jdbc:testdb").split(body()).to("mock:result");
If we want to poll a database using the JDBC component, we need to combine it with a polling scheduler such as the Timer or Quartz etc. In the following example, we retrieve data from the database every 60 seconds:
from("timer://foo?period=60000").setBody(constant("select * from customer")).to("jdbc:testdb").to("activemq:queue:customers");See also:
The Jing component uses the Jing Library to perform XML validation of the message body using either:
Note that the MSV component can also support RelaxNG XML syntax.
rng:someLocalOrRemoteResource rnc:someLocalOrRemoteResource
Where rng means use the RelaxNG XML Syntax whereas rnc means use RelaxNG Compact Syntax. The following examples show possible URI values
| Example | Description |
|---|---|
rng:foo/bar.rng
|
References the XML file foo/bar.rng on the classpath |
rnc:http://foo.com/bar.rnc
|
References the RelaxNG Compact Syntax file from the URL,
http://foo.com/bar.rnc. |
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default | Description |
|---|---|---|
useDom
|
false
|
Apache Camel 2.0: Specifies whether DOMSource/DOMResult or SaxSource/SaxResult should be used by the validator. |
The following example shows how to configure a route from the endpoint direct:start which then goes to one of two endpoints, either mock:valid or mock:invalid based on whether or not the XML matches the given RelaxNG Compact Syntax schema (which is supplied on the classpath).
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<doTry>
<to uri="rnc:org/apache/camel/component/validator/jing/schema.rnc"/>
<to uri="mock:valid"/>
<doCatch>
<exception>org.apache.camel.ValidationException</exception>
<to uri="mock:invalid"/>
</doCatch>
<doFinally>
<to uri="mock:finally"/>
</doFinally>
</doTry>
</route>
</camelContext>
Component allows consumers to subscribe to an mbean's Notifications. The component supports passing the Notification object directly through the Exchange or serializing it to XML according to the schema provided within this project. This is a consumer only component. Exceptions are thrown if you attempt to create a producer for it.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jmx</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>The component can connect to the local platform mbean server with the following URI:
jmx://platform?options
A remote mbean server url can be provided following the initial JMX scheme like so:
jmx:service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi?options
You can append query options to the URI in the following format, ?options=value&option2=value&...
| Property | Required | Default | Description |
|---|---|---|---|
| format | xml | Format for the message body. Either "xml" or "raw". If xml, the notification is serialized to xml. If raw, then the raw java object is set as the body. | |
| password | Credentials for making a remote connection. | ||
| objectDomain | yes | The domain for the mbean you're connecting to. | |
| objectName | The name key for the mbean you're connecting to. This value is mutually exclusive with the object properties that get passed. (see below) | ||
| notificationFilter | Reference to a bean that implements the NotificationFilter. The #ref syntax should be used to reference the bean via the Registry. |
||
| handback | Value to handback to the listener when a notification is received. This value will be put in the message header with the key "jmx.handback" |
The URI must always have the objectDomain property. In addition, the URI must contain either objectName or one or more properties that start with "key."
When the objectName property is provided, the following constructor is used to build the ObjectName? for the mbean:
ObjectName(String domain, String key, String value)
The key value in the above will be "name" and the value will be the value of the objectName property.
ObjectName(String domain, Hashtable<String,String> table)
The Hashtable is constructed by extracting properties that start with "key." The properties will have the "key." prefixed stripped prior to building the Hashtable. This allows the URI to contain a variable number of properties to identify the mbean.
from("jmx:platform?objectDomain=jmxExample&key.name=simpleBean").
to("log:jmxEvent");
The jpa component enables you to store and retrieve Java objects from persistent storage using EJB 3's Java Persistence Architecture (JPA), which is a standard interface layer that wraps Object/Relational Mapping (ORM) products such as OpenJPA, Hibernate, TopLink, and so on.
You can store a Java entity bean in a database by sending it to a JPA producer endpoint. The body of the In message is assumed to be an entity bean (that is, a POJO with an @Entity annotation on it) or a collection or an array of entity beans.
If the body does not contain one of the preceding types, put a Message TranslatorMessage Translator in front of the endpoint to perform the necessary conversion first.
Consuming messages from a JPA consumer endpoint removes (or updates) entity beans in the database. This allows you to use a database table as a logical queue: consumers 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 bean 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.
jpa:[entityClassName][?options]
For sending to the endpoint, the entityClassName is optional. If specified, it helps the Type Converter to ensure the body is of the correct type.
For consuming, the entityClassName is mandatory.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
entityType
|
entityClassName | Overrides the entityClassName from the URI. |
persistenceUnit
|
camel
|
The JPA persistence unit used by default. |
consumeDelete
|
true
|
JPA consumer only: If true, the
entity is deleted after it is consumed; if false, the entity is not
deleted. |
consumeLockEntity
|
true
|
JPA consumer only: Specifies whether or not to set an exclusive lock on each entity bean while processing the results from polling. |
flushOnSend
|
true
|
JPA producer only: Flushes the EntityManager after the entity bean has been persisted. |
maximumResults
|
-1
|
JPA consumer only: Set the maximum number of results to retrieve on the Query. |
transactionManager
|
null
|
Apache Camel 1.6.1/2.0: Specifies the transaction manager
to use. If none provided, Apache Camel will use a JpaTransactionManager by
default. Can be used to set a JTA transaction manager (for integration with an EJB
container). |
consumer.delay
|
500
|
JPA consumer only: Delay in milliseconds between each poll. |
consumer.initialDelay
|
1000
|
JPA consumer only: Milliseconds before polling starts. |
consumer.useFixedDelay
|
false
|
JPA consumer only: Set to true to
use fixed delay between polls, otherwise fixed rate is used. See ScheduledExecutorService in JDK for details. |
maxMessagesPerPoll
|
0
|
Apache Camel 2.0:JPA consumer only: An integer value to define the maximum number of messages to gather per poll. By default, no maximum is set. Can be used to avoid polling many thousands of messages when starting up the server. Set a value of 0 or negative to disable. |
consumer.query
|
JPA consumer only: To use a custom query when consuming data. | |
consumer.resultClass
|
Camel 2.7: JPA consumer only: Defines the type of the returned payload (we will call entityManager.createNativeQuery(nativeQuery, resultClass) instead of entityManager.createNativeQuery(nativeQuery)). Without this option, we will return an object array. Only has an affect when using in conjunction with native query when consuming data. |
|
consumer.namedQuery
|
JPA consumer only: To use a named query when consuming data. | |
consumer.nativeQuery
|
JPA consumer only: To use a custom native query when consuming data. | |
usePersist
|
false
|
Camel 2.5: JPA producer only: Indicates to use
entityManager.persist(entity) instead of entityManager.merge(entity).
Note: entityManager.persist(entity) doesn't work for detached entities
(where the EntityManager has to execute an UPDATE instead of an INSERT query)! |
Apache Camel adds the following message headers to the exchange:
| Header | Type | Description |
|---|---|---|
CamelJpaTemplate
|
JpaTemplate
|
Apache Camel 2.0: The JpaTemplate object
that is used to access the entity bean. You need this object in some situations, for
instance in a type converter or when you are doing some custom processing. |
You are strongly advised to configure the JPA component to use a specific
EntityManagerFactory instance. If you do not do so, each
JpaEndpoint will auto-create its own EntityManagerFactory
instance.For example, you can instantiate a JPA component that references the
myEMFactory entity manager factory, as follows:
<bean id="jpa" class="org.apache.camel.component.jpa.JpaComponent"> <property name="entityManagerFactory" ref="myEMFactory"/> </bean>
In Camel 2.3 the
JpaComponent will auto lookup the EntityManagerFactory
from the Registry which means you do not need to configure
this on the JpaComponent as shown above. You only need to do so if there is
ambiguity, in which case Camel will log a WARN.
You are strongly advised to specify the TransactionManager instance
used by the JPA component. If you do not do so, each JpaEndpoint will auto-create
its own instance of TransactionManager. For example, you can instantiate a
JPA component that references the myTransactionManager transaction manager,
as follows:
<bean id="jpa" class="org.apache.camel.component.jpa.JpaComponent"> <property name="entityManagerFactory" ref="myEMFactory"/> <property name="transactionManager" ref="myTransactionManager"/> </bean>
In Camel 2.3 the
JpaComponent will auto lookup the TransactionManager
from the Registry which means you do not need to configure
this on the JpaComponent as shown above. You only need to do so if there is
ambiguity, in which case Camel will log a WARN.
For consuming only selected entities, you can use the
consumer.namedQuery URI query option. First, you have to define the named
query in the JPA Entity class:
@Entity
@NamedQuery(name = "step1", query = "select x from MultiSteps x where x.step = 1")
public class MultiSteps {
...
}
After that you can define a consumer uri like this one:
from("jpa://org.apache.camel.examples.MultiSteps?consumer.namedQuery=step1")
.to("bean:myBusinessLogic");
For consuming only selected entities, you can use the consumer.query
URI query option. You only have to define the query option:
from("jpa://org.apache.camel.examples.MultiSteps?consumer.query=select o from org.apache.camel.examples.MultiSteps o where o.step = 1")
.to("bean:myBusinessLogic");
For consuming only selected entities, you can use the
consumer.nativeQuery URI query option. You only have to define the native
query option:
from("jpa://org.apache.camel.examples.MultiSteps?consumer.nativeQuery=select * from MultiSteps where step = 1")
.to("bean:myBusinessLogic");
If you use the native query option, you will receive an object array in the message body.
The jt400 component allows you to
exchanges messages with an AS/400 system using data queues.
jt400://user:password@system/QSYS.LIB/LIBRARY.LIB/QUEUE.DTAQ[?options]
To call a remote program (Camel 2.7)
jt400://user:password@system/QSYS.LIB/LIBRARY.LIB/program.PGM[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
For the data queue message exchange:
| Name | Default value | Description |
|---|---|---|
ccsid
|
default system CCSID | Specifies the CCSID to use for the connection with the AS/400 system. |
format
|
text
|
Specifies the data format for sending messages valid options are:
text (represented by String) and
binary (represented by byte[]) |
consumer.delay
|
500
|
Delay in milliseconds between each poll. |
consumer.initialDelay
|
1000
|
Milliseconds before polling starts. |
consumer.userFixedDelay
|
false
|
true to use fixed delay between polls, otherwise fixed rate is used.
See ScheduledExecutorService in JDK for details. |
For the remote program call (Camel 2.7):
| Name | Default value | Description |
|---|---|---|
outputFieldsIdx
|
Specifies which fields (program parameters) are output parameters. | |
fieldsLength
|
Specifies the fields (program parameters) length as in the AS/400 program definition. |
When configured as a consumer endpoint, the endpoint will poll a data queue on a remote
system. For every entry on the data queue, a new Exchange is sent with the
entry's data in the In message's body, formatted either as a
String or a byte[], depending on the format. For a
provider endpoint, the In message body contents will be put on the data
queue as either raw bytes or text.
This endpoint expects the input to be a String array and handles all the CCSID handling trough the native jt400 library mechanisms. After the program execution the endpoint returns a String array with the values as they were returned by the program (the input only parameters will contain the same data as the beginning of the invocation) This endpoint does not implement a provider endpoint!
In the snippet below, the data for an exchange sent to the
direct:george endpoint will be put in the data queue
PENNYLANE in library BEATLES on a system named
LIVERPOOL. Another user connects to the same data queue to receive the
information from the data queue and forward it to the mock:ringo
endpoint.
public class Jt400RouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:george").to("jt400://GEORGE:EGROEG@LIVERPOOL/QSYS.LIB/BEATLES.LIB/PENNYLANE.DTAQ");
from("jt400://RINGO:OGNIR@LIVERPOOL/QSYS.LIB/BEATLES.LIB/PENNYLANE.DTAQ").to("mock:ringo");
}
}In the snippet below, the data Exchange sent to the direct:work endpoint will contain three string that will be used as the arguments for the program "compute" in the library "assets". This program will write the output values in the 2nd and 3rd parameters. All the parameters will be sent to the direct:play endpoint.
public class Jt400RouteBuilder extends RouteBuilder {
@Override
public void configure() throws Exception {
from("direct:work").to("jt400://GRUPO:ATWORK@server/QSYS.LIB/assets.LIB/compute.PGM?fieldsLength=10,10,512&ouputFieldsIdx=2,3").to("direct:play");
}
}The language component allows you to send Exchange to an endpoint which executes a script by any of the supported Languages in Camel.
By having a component to execute language scripts, it allows more dynamic routing capabilities. For example by using the Routing SlipRouting Slip or Dynamic RouterDynamic Router EIPs you can send messages to language endpoints where the script is dynamic defined as well.
This component is provided out of the box in camel-core and hence no additional JARs is needed. You only have to include additional Camel components if the language of choice mandates it, such as using Groovy or JavaScript languages.
The component supports the following options.
| Name | Default Value | Type | Description |
|---|---|---|---|
languageName
|
null
|
String
|
The name of the Language to use, such as simple, groovy, javascript etc. This option is mandatory. |
script
|
null
|
String
|
The script to execute. |
transform
|
true
|
boolean
|
Whether or not the result of the script should be used as the new message body. By setting to false the script is executed but the result of the script is discarded. |
The following message headers can be used to affect the behavior of the component
| Header | Description |
|---|---|
CamelLanguageScript
|
The script to execute provided in the header. Takes precedence over script configured on the endpoint. |
For example you can use the Simple language to Message TranslatorMessage Translator a message:
from("direct:start").to("language:simple:Hello ${body}").to("mock:result");
In case you want to convert the message body type you can do this as well:
from("direct:start").to("language:simple:${mandatoryBodyAs(String)}").to("mock:result");
You can also use the Groovy language, such as this example where the input message will by multiplied with 2:
from("direct:start").to("language:groovy:request.body * 2").to("mock:result");
You can also provide the script as a header as shown below. Here we use XPath language to extract the text from the <foo> tag.
Object out = producer.requestBodyAndHeader("language:xpath", "<foo>Hello World</foo>", Exchange.LANGUAGE_SCRIPT, "/foo/text()");
assertEquals("Hello World", out);
Routing SlipRouting Slip
Dynamic RouterDynamic Router
The ldap component allows you to perform searches in LDAP
servers using filters as the message payload. This component uses standard JNDI
(javax.naming package) to access the server.
ldap:ldapServerBean[?options]
The ldapServerBean portion of the URI refers to a DirContext bean in the registry. The LDAP component only supports producer
endpoints, which means that an ldap URI cannot appear in the
from at the start of a route.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
base
|
ou=system
|
The base DN for searches. |
scope
|
subtree
|
Specifies how deeply to search the tree of entries, starting at the base DN. Value can
be object, onelevel, or subtree.
|
pageSize
|
No paging used. | When specified the LDAP module uses paging to retrieve all results (most LDAP Servers
throw an exception when trying to retrieve more than 1000 entries in one query). To be
able to use this, an LdapContext (subclass of DirContext) has to
be passed in as ldapServerBean (otherwise an exception is thrown) |
returnedAttributes |
Depends on LDAP Server (could be all or none) . | Comma-separated list of attributes that should be set in each entry of the result |
The result is returned in the Out body as a
ArrayList<javax.naming.directory.SearchResult> object.
The URI, ldap:ldapserver, references a Spring bean with the ID,
ldapserver. The ldapserver bean may be defined as
follows:
<bean id="ldapserver" class="javax.naming.directory.InitialDirContext" scope="prototype">
<constructor-arg>
<props>
<prop key="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</prop>
<prop key="java.naming.provider.url">ldap://localhost:10389</prop>
<prop key="java.naming.security.authentication">none</prop>
</props>
</constructor-arg>
</bean>The preceding example declares a regular Sun based LDAP DirContext that
connects anonymously to a locally hosted LDAP server.
| Note |
|---|---|
|
| Note |
|---|---|
Apache Camel 1.6.1 and Apache Camel 2.0 include a fix to support concurrency for LDAP producers. ldapServerBean contexts are now looked up each time a request is sent to the LDAP server. In addition, the contexts are released as soon as the producer completes. |
Following on from the Spring configuration above, the code sample below sends an LDAP request to filter search a group for a member. The Common Name is then extracted from the response.
ProducerTemplate<Exchange> template = exchange
.getContext().createProducerTemplate();
Collection<?> results = (Collection<?>) (template
.sendBody(
"ldap:ldapserver?base=ou=mygroup,ou=groups,ou=system",
"(member=uid=huntc,ou=users,ou=system)"));
if (results.size() > 0) {
// Extract what we need from the device's profile
Iterator<?> resultIter = results.iterator();
SearchResult searchResult = (SearchResult) resultIter
.next();
Attributes attributes = searchResult
.getAttributes();
Attribute deviceCNAttr = attributes.get("cn");
String deviceCN = (String) deviceCNAttr.get();
...If no specific filter is required - for example, you just need to look up a single entry - specify a wildcard filter expression. For example, if the LDAP entry has a Common Name, use a filter expression like:
(cn=*)
A Camel end user donated this sample code he used to bind to the ldap server using credentials.
Properties props = new Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
props.setProperty(Context.PROVIDER_URL, "ldap://localhost:389");
props.setProperty(Context.URL_PKG_PREFIXES, "com.sun.jndi.url");
props.setProperty(Context.REFERRAL, "ignore");
props.setProperty(Context.SECURITY_AUTHENTICATION, "simple");
props.setProperty(Context.SECURITY_PRINCIPAL, "cn=Manager");
props.setProperty(Context.SECURITY_CREDENTIALS, "secret");
SimpleRegistry reg = new SimpleRegistry();
reg.put("myldap", new InitialLdapContext(props, null));
CamelContext context = new DefaultCamelContext(reg);
context.addRoutes(
new RouteBuilder() {
public void configure() throws Exception {
from("direct:start").to("ldap:myldap?base=ou=test");
}
}
);
context.start();
ProducerTemplate template = context.createProducerTemplate();
Endpoint endpoint = context.getEndpoint("direct:start");
Exchange exchange = endpoint.createExchange();
exchange.getIn().setBody("(uid=test)");
Exchange out = template.send(endpoint, exchange);
Collection<SearchResult> data = out.getOut().getBody(Collection.class);
assert data != null;
assert !data.isEmpty();
System.out.println(out.getOut().getBody());
context.stop();deprecated: is renamed to the Browse component in Apache Camel 2.0
The List component provides a simple BrowsableEndpoint which can be useful for testing, visualisation tools or debugging. The exchanges sent to the endpoint are all available to be browsed.
In the route below we have the list component to be able to browse the Exchanges that is passed through:
from("activemq:order.in").to("list:orderReceived").to("bean:processOrder");Then we will be able to inspect the received exchanges from java code:
private CamelContext context;
public void inspectRecievedOrders() {
BrowsableEndpoint browse = context.getEndpoint("list:orderReceived", BrowsableEndpoint.class);
List<Exchange> exchanges = browse.getExchanges();
...
// then we can inspect the list of received exchanges from Java
for (Exchange exchange : exchanges) {
String payload = exchange.getIn().getBody();
...
}
}See also:
log:loggingCategory[?options]
Where loggingCategory is the name of the logging category
to use. You can append query options to the URI in the following format,
?option=value&option=value&...
For example, a log endpoint typically specifies the logging level using the
level option, as follows:
log:org.apache.camel.example?level=DEBUG
The default logger logs every exchange (regular logging). But
Apache Camel also ships with the Throughput logger, which is used whenever the
groupSize option is specified.
| Also a log in the DSL |
|---|---|
In Camel 2.2 onwards there is a |
| Option | Default | Type | Description |
|---|---|---|---|
level
|
INFO
|
String
|
Logging level to use. Possible values: FATAL,
ERROR, WARN, INFO,
DEBUG, TRACE, OFF
|
groupSize
|
null
|
Integer
|
An integer that specifies a group size for throughput logging. By default, regular logging is used. |
The log formats the execution of exchanges to log lines. By default, the log uses
LogFormatter to format the log output, where
LogFormatter has the following options:
| Option | Default | Description |
|---|---|---|
showAll
|
false
|
Quick option for turning all options on (multiline, maxChars has to be manually set if to be used). |
showExchangeId
|
false
|
Show the unique exchange ID. |
showExchangePattern
|
true
|
Camel 2.3: Shows the Message Exchange Pattern (or MEP for short). |
showProperties
|
false
|
Show the exchange properties. |
showHeaders
|
false
|
Show the In message headers. |
showBodyType
|
true
|
Show the In body Java type. |
showBody
|
true
|
Show the In body. |
showOut
|
false
|
If the exchange has an Out message, show the Out message. |
showException
|
false
|
Apache Camel 2.0: If the exchange has an exception, show the exception message (no stack trace). |
showCaughtException
|
false
|
Apache Camel 2.0: If the exchange has a caught exception,
show the exception message (no stack trace). A caught exception is stored as a property on
the exchange and for instance a doCatch can catch exceptions. See Try Catch Finally. |
showStackTrace
|
false
|
Apache Camel 2.0: Show the stack trace, if an exchange has an exception. |
showFuture
|
false
|
Camel 2.1: Whether Camel should show java.util.concurrent.Future bodies or not. If enabled Camel could potentially wait until the Future task is done. Will by default not wait. |
multiline
|
false
|
If true, each piece of information is logged on a new line. |
maxChars
|
Apache Camel 2.0: Limits the number of characters logged per line. |
In the route below we log the incoming orders at DEBUG level before the
order is processed:
<route>
<from uri="activemq:orders"/>
<to uri="log:com.mycompany.order?level=DEBUG"/>
<to uri="bean:processOrder"/>
</route> In the route below we log the incoming orders at INFO level before the
order is processed.
from("activemq:orders").
to("log:com.mycompany.order?showAll=true&multiline=true").to("bean:processOrder");Available as of Apache Camel 2.2
The lucene component is based on the Apache Lucene project. Apache Lucene is a powerful high-performance, full-featured text search engine library written entirely in Java. For more details about Lucene, please see the following links * http://lucene.apache.org/java/docs/ * http://lucene.apache.org/java/docs/features.html
The lucene component in camel facilitates integration and utilization of Lucene endpoints in enterprise integration patterns and scenarios. The lucene component does the following
builds a searchable index of documents when payloads are sent to the Lucene Endpoint
facilitates performing of indexed searches in Apache Camel
This component only supports producer endpoints.
lucene:searcherName:insert[?options] lucene:searcherName:query[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
analyzer
|
StandardAnalyzer
|
An Analyzer builds TokenStreams, which analyze text. It thus represents a policy for extracting index terms from text. The value for analyzer can be any class that extends the abstract class org.apache.lucene.analysis.Analyzer. Lucene also offers a rich set of analyzers out of the box |
indexDir
|
./indexDirectory
|
A file system directory in which index files are created upon analysis of the document by the specified analyzer |
srcDir
|
null
|
An optional directory containing files to be used to be analyzed and added to the index at producer startup. |
| Name | Default Value | Description |
|---|---|---|
analyzer
|
StandardAnalyzer
|
An Analyzer builds TokenStreams, which analyze text. It thus represents a policy for extracting index terms from text. The value for analyzer can be any class that extends the abstract class org.apache.lucene.analysis.Analyzer. Lucene also offers a rich set of analyzers out of the box |
indexDir
|
./indexDirectory
|
A file system directory in which index files are created upon analysis of the document by the specified analyzer |
maxHits
|
10
|
An integer value that limits the result set of the search operation |
| Header | Description |
|---|---|
QUERY
|
The Lucene Query to performed on the index. The query may include wildcards and phrases |
This component supports 2 producer endpoints.
insert - The insert producer builds a searchable index by analyzing the body in incoming exchanges and associating it with a token ("content").
query - The query producer performs searches on a pre-created index. The query uses the searchable index to perform score & relevance based searches. Queries are sent via the incoming exchange contains a header property name called 'QUERY'. The value of the header property 'QUERY' is a Lucene Query. For more details on how to create Lucene Queries check out http://lucene.apache.org/java/3_0_0/queryparsersyntax.html
There is a processor called LuceneQueryProcessor available to perform queries against lucene without the need to create a producer.
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start").
to("lucene:whitespaceQuotesIndex:insert?analyzer=#whitespaceAnalyzer&indexDir=#whitespace&srcDir=#load_dir").
to("mock:result");
}
};@Override
protected JndiRegistry createRegistry() throws Exception {
JndiRegistry registry =
new JndiRegistry(createJndiContext());
registry.bind("whitespace", new File("./whitespaceIndexDir"));
registry.bind("load_dir",
new File("src/test/resources/sources"));
registry.bind("whitespaceAnalyzer",
new WhitespaceAnalyzer());
return registry;
}
...
CamelContext context = new DefaultCamelContext(createRegistry());RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("direct:start").
setHeader("QUERY", constant("Seinfeld")).
to("lucene:searchIndex:query?analyzer=#whitespaceAnalyzer&indexDir=#whitespace&maxHits=20").
to("direct:next");
from("direct:next").process(new Processor() {
public void process(Exchange exchange) throws Exception {
Hits hits = exchange.getIn().getBody(Hits.class);
printResults(hits);
}
private void printResults(Hits hits) {
LOG.debug("Number of hits: " + hits.getNumberOfHits());
for (int i = 0; i < hits.getNumberOfHits(); i++) {
LOG.debug("Hit " + i + " Index Location:" + hits.getHit().get(i).getHitLocation());
LOG.debug("Hit " + i + " Score:" + hits.getHit().get(i).getScore());
LOG.debug("Hit " + i + " Data:" + hits.getHit().get(i).getData());
}
}
}).to("mock:searchResult");
}
};RouteBuilder builder = new RouteBuilder() {
public void configure() {
try {
from("direct:start").
setHeader("QUERY", constant("Rodney Dangerfield")).
process(new LuceneQueryProcessor("target/stdindexDir", analyzer, null, 20)).
to("direct:next");
} catch (Exception e) {
e.printStackTrace();
}
from("direct:next").process(new Processor() {
public void process(Exchange exchange) throws Exception {
Hits hits = exchange.getIn().getBody(Hits.class);
printResults(hits);
}
private void printResults(Hits hits) {
LOG.debug("Number of hits: " + hits.getNumberOfHits());
for (int i = 0; i < hits.getNumberOfHits(); i++) {
LOG.debug("Hit " + i + " Index Location:" + hits.getHit().get(i).getHitLocation());
LOG.debug("Hit " + i + " Score:" + hits.getHit().get(i).getScore());
LOG.debug("Hit " + i + " Data:" + hits.getHit().get(i).getData());
}
}
}).to("mock:searchResult");
}
};The mina: component is a transport for working with Apache MINA
mina:tcp://hostname[:port][?options] mina:udp://hostname[:port][?options] mina:vm://hostname[:port][?options]
From Apache Camel 1.3 onwards you can specify a codec in the Registry using the codec option. If you are
using TCP and no codec is specified then the textline flag is used to
determine if text line based codec or object serialization should be used instead. By
default the object serialization is used.
For UDP, if no codec is specified the default uses a basic
ByteBuffer based codec.
The VM protocol is used as a direct forwarding mechanism in the same JVM. See the MINA VM-Pipe API documentation for details.
A Mina producer has a default timeout value of 30 seconds, while it waits for a response from the remote server.
In normal use, camel-mina only supports marshalling the body
content—essage headers and exchange properties are not sent. However, the option,
transferExchange, does allow you to transfer the
exchange itself over the wire. See options below.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default Value | Description |
|---|---|---|
codec
|
null
|
As of 1.3, you can refer to a named ProtocolCodecFactory
instance in your Registry such as your Spring
ApplicationContext, which is then used for the
marshalling. |
codec
|
null
|
Apache Camel 2.0: You must use the
# notation to look up your codec in the Registry. For example, use
#myCodec to look up a bean with the id
value, myCodec. |
disconnect
|
false
|
Camel 2.3: Whether or not to disconnect(close) from Mina session right after use. Can be used for both consumer and producer. |
textline
|
false
|
Only used for TCP. If no codec is specified, you can use this flag in 1.3 or
later to indicate a text line based codec; if not specified or the value is
false, then Object Serialization is assumed over TCP.
|
textlineDelimiter
|
DEFAULT
|
Apache Camel 1.6.0/2.0 Only used for TCP and if
textline=true. Sets the text line delimiter
to use. Possible values are: DEFAULT,
AUTO, WINDOWS, UNIX or
MAC. If none provided, Apache Camel will use
DEFAULT. This delimiter is used to mark the end of text.
|
sync
|
true
|
As of 1.3, you can configure the exchange pattern to be either InOnly (default)
or InOut. Setting sync=true means a synchronous exchange
(InOut), where the client can read the response from MINA (the exchange Out
message). The default value has changed in Apache Camel 1.5 to
true. In older releases, the default value is
false. |
lazySessionCreation
|
See description | As of 1.3, sessions can be lazily created to avoid exceptions, if the remote
server is not up and running when the Apache Camel producer is started. From
Apache Camel 2.0 onwards, the default is true. In Apache Camel 1.x,
the default is false. |
timeout
|
30000
|
As of 1.3, you can configure the timeout that specifies how long to wait for a response from a remote server. The timeout unit is in milliseconds, so 60000 is 60 seconds. The timeout is only used for Mina producer. |
encoding
|
JVM Default | As of 1.3, you can configure the encoding (a charset name) to use for the TCP textline codec and the UDP protocol. If not provided, Apache Camel will use the JVM default Charset. |
transferExchange
|
false
|
Only used for TCP. As of 1.3, you can transfer the exchange over the wire
instead of just the body. The following fields are transferred: In body, Out
body, fault body, In headers, Out headers, fault headers, exchange properties,
exchange exception. This requires that the objects are
serializable. Apache Camel will exclude any
non-serializable objects and log it at WARN level. |
minaLogger
|
false
|
As of 1.3, you can enable the Apache MINA logging filter. Apache MINA uses
slf4j logging at INFO level to log all
input and output. |
filters
|
null
|
As of 2.0, you can set a list of Mina IoFilters to
register. The
|
encoderMaxLineLength
|
-1
|
As of 2.1, you can set the textline protocol encoder max line length. By
default the default value of Mina itself is used which are
Integer.MAX_VALUE. |
decoderMaxLineLength
|
-1
|
As of 2.1, you can set the textline protocol decoder max line length. By default the default value of Mina itself is used which are 1024. |
allowDefaultCodec
|
true
|
The mina component installs a default codec if both, codec
is null and textline is
false. Setting allowDefaultCodec to
false prevents the mina component from installing a
default codec as the first element in the filter chain. This is useful in
scenarios where another filter must be the first in the filter chain, like the
SSL filter. |
disconnectOnNoReply
|
true
|
Camel 2.3: If sync is enabled then this option dictates MinaConsumer if it should disconnect where there is no reply to send back. |
noReplyLogLevel
|
WARN
|
Camel 2.3: If sync is enabled this option
dictates MinaConsumer which logging level to use when logging a there is no
reply to send back. Values are: FATAL, ERROR, INFO, DEBUG,
OFF. |
In Apache Camel 2.0 the codec option must
use # notation for lookup of the codec bean in the Registry. In Apache Camel 2.0 the lazySessionCreation option now defaults to
true.
In Apache Camel 1.5 the sync option has changed its
default value from false to true, as we felt it
was confusing for end-users when they used Mina to
call remote servers and Apache Camel wouldn't wait for the response.
In Apache Camel 1.4 or later codec=textline is no
longer supported. Use the textline=true option instead.
See the Mina documentation how to write your own codec. To use your custom codec
with camel-mina, you should register your codec in the Registry; for example, by creating a bean in the Spring
XML file. Then use the codec option to specify the bean ID of your
codec.
In this sample, Apache Camel exposes a service that listens for TCP connections on port 6200. We use the textline codec. In our route, we create a Mina consumer endpoint that listens on port 6200:
from("mina:tcp://localhost:6200?textline=true&sync=false").to("mock:result");As the sample is part of a unit test, we test it by sending some data to it on port 6200.
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedBodiesReceived("Hello World");
template.sendBody("mina:tcp://localhost:6200?textline=true&sync=false", "Hello World");
assertMockEndpointsSatisfied();In the next sample, we have a more common use case where we expose a TCP service on
port 6201 also use the textline codec. However, this time we want to return a response,
so we set the sync option to true on the consumer.
from("mina:tcp://localhost:6201?textline=true&sync=true").process(new Processor() {
public void process(Exchange exchange) throws Exception {
String body = exchange.getIn().getBody(String.class);
exchange.getOut().setBody("Bye " + body);
}
});Then we test the sample by sending some data and retrieving the response using the
template.requestBody() method. As we know the response is a
String, we cast it to String and can assert
that the response is, in fact, something we have dynamically set in our processor code
logic.
String response = (String)template.requestBody("mina:tcp://localhost:6201?textline=true&sync=true", "World");
assertEquals("Bye World", response);XML DSL can, of course, also be used for Mina. In the sample below we expose a TCP server on port 5555:
<route>
<from uri="mina:tcp://localhost:5555?textline=true"/>
<to uri="bean:myTCPOrderHandler"/>
</route>In the route above, we expose a TCP server on port 5555 using the textline codec. We
let the Spring bean with ID, myTCPOrderHandler, handle the request
and return a reply. For instance, the handler bean could be implemented as
follows:
public String handleOrder(String payload) {
...
return "Order: OK"
}Available as of Apache Camel 2.0
Configuration of Mina endpoints is now possible using regular Spring bean style configuration in the Spring DSL.
However, in the underlying Apache Mina toolkit, it is relatively difficult to set up
the acceptor and the connector, because you can not use simple
setters. To resolve this difficulty, we leverage the MinaComponent as
a Spring factory bean to configure this for us. If you really need to configure this
yourself, there are setters on the MinaEndpoint to set these when
needed.
The sample below shows the factory approach:
<!-- Creating mina endpoints is a bit complex so we reuse MinaComponnet
as a factory bean to create our endpoint, this is the easiest to do -->
<bean id="myMinaFactory" class="org.apache.camel.component.mina.MinaComponent">
<!-- we must provide a camel context so we refer to it by its id -->
<constructor-arg index="0" ref="myCamel"/>
</bean>
<!-- This is our mina endpoint configured with Spring, we will use the factory above
to create it for us. The goal is to invoke the createEndpoint method with the
mina configuration parameter we defined using the constructor-arg option -->
<bean id="myMinaEndpoint"
factory-bean="myMinaFactory"
factory-method="createEndpoint">
<!-- and here we can pass it our configuration -->
<constructor-arg index="0" ref="myMinaConfig"/>
</bean>
<!-- this is our mina configuration with plain properties -->
<bean id="myMinaConfig" class="org.apache.camel.component.mina.MinaConfiguration">
<property name="protocol" value="tcp"/>
<property name="host" value="localhost"/>
<property name="port" value="1234"/>
<property name="sync" value="false"/>
</bean>And then we can refer to our endpoint directly in the route, as follows:
<route>
<!-- here we route from or mina endpoint we have defined above -->
<from ref="myMinaEndpoint"/>
<to uri="mock:result"/>
</route>Available as of Apache Camel 1.6.1
When acting as a server you sometimes want to close the session when, for example, a
client conversion is finished. To instruct Apache Camel to close the session, you should add
a header with the key CamelMinaCloseSessionWhenComplete set to a
boolean true value.
For instance, the example below will close the session after it has written the
bye message back to the client:
from("mina:tcp://localhost:8080?sync=true&textline=true").process(new Processor() {
public void process(Exchange exchange) throws Exception {
String body = exchange.getIn().getBody(String.class);
exchange.getOut().setBody("Bye " + body);
exchange.getOut().setHeader(MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE, true);
}
});Available since Apache Camel 2.1 You can get the
IoSession from the message header with this key
MinaEndpoint.HEADER_MINA_IOSESSION, and also get the local host address
with the key MinaEndpoint.HEADER_LOCAL_ADDRESS and remote host address with
the key MinaEndpoint.HEADER_REMOTE_ADDRESS.
Available since Apache Camel 2.0
Filters permit you to use some Mina Filters, such as SslFilter. You
can also implement some customized filters. Please note that codec
and logger are also implemented as Mina filters of type,
IoFilter. Any filters you may define are appended to the end of
the filter chain; that is, after codec and
logger.
For instance, the example below will send a keep-alive message after 10 seconds of inactivity:
public class KeepAliveFilter extends IoFilterAdapter {
@Override
public void sessionCreated(NextFilter nextFilter, IoSession session)
throws Exception {
session.setIdleTime(IdleStatus.BOTH_IDLE, 10);
nextFilter.sessionCreated(session);
}
@Override
public void sessionIdle(NextFilter nextFilter, IoSession session,
IdleStatus status) throws Exception {
session.write("NOOP"); // NOOP is a FTP command for keep alive
nextFilter.sessionIdle(session, status);
}
}As Apache Camel Mina may use a request-reply scheme, the endpoint as a client would like
to drop some message, such as greeting when the connection is established. For example,
when you connect to an FTP server, you will get a 220 message with a
greeting (220 Welcome to Pure-FTPd). If you don't drop the message,
your request-reply scheme will be broken.
public class DropGreetingFilter extends IoFilterAdapter {
@Override
public void messageReceived(NextFilter nextFilter, IoSession session,
Object message) throws Exception {
if (message instanceof String) {
String ftpMessage = (String) message;
// "220" is given as greeting. "200 Zzz" is given as a response to "NOOP" (keep alive)
if (ftpMessage.startsWith("220") || or ftpMessage.startsWith("200 Zzz")) {
// Dropping greeting
return;
}
}
nextFilter.messageReceived(session, message);
}
}Then, you can configure your endpoint using XML DSL:
<bean id="myMinaFactory" class="org.apache.camel.component.mina.MinaComponent">
<constructor-arg index="0" ref="camelContext" />
</bean>
<bean id="myMinaEndpoint"
factory-bean="myMinaFactory"
factory-method="createEndpoint">
<constructor-arg index="0" ref="myMinaConfig"/>
</bean>
<bean id="myMinaConfig" class="org.apache.camel.component.mina.MinaConfiguration">
<property name="protocol" value="tcp" />
<property name="host" value="localhost" />
<property name="port" value="2121" />
<property name="sync" value="true" />
<property name="minaLogger" value="true" />
<property name="filters" ref="listFilters"/>
</bean>
<bean id="listFilters" class="java.util.ArrayList" >
<constructor-arg>
<list value-type="org.apache.mina.common.IoFilter">
<bean class="com.example.KeepAliveFilter"/>
<bean class="com.example.DropGreetingFilter"/>
</list>
</constructor-arg>
</bean>The MSV component performs XML validation of the message body using the MSV Library and any of the supported XML schema languages, such as XML Schema or RelaxNG XML Syntax.
Note that the Jing component also supports RelaxNG Compact Syntax
msv:someLocalOrRemoteResource[?options]
Where someLocalOrRemoteResource is some URL to a local resource on the classpath or a full URL to a remote resource or resource on the file system. For example
msv:org/foo/bar.rng msv:file:../foo/bar.rng msv:http://acme.com/cheese.rng
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default | Description |
|---|---|---|
useDom
|
true
|
Apache Camel 2.0: Whether DOMSource/DOMResult or SaxSource/SaxResult should be used by the validator. Note: DOM must be used by the MSV component. |
The following example shows how to configure a route from endpoint direct:start which then goes to one of two endpoints, either mock:valid or mock:invalid based on whether or not the XML matches the given RelaxNG XML Schema (which is supplied on the classpath).
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<doTry>
<to uri="msv:org/apache/camel/component/validator/msv/schema.rng"/>
<to uri="mock:valid"/>
<doCatch>
<exception>org.apache.camel.ValidationException</exception>
<to uri="mock:invalid"/>
</doCatch>
<doFinally>
<to uri="mock:finally"/>
</doFinally>
</doTry>
</route>
</camelContext>
Available as of Camel 2.7
The mybatis: component allows you to query, poll, insert, update and delete data in a relational database using MyBatis.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-mybatis</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
mybatis:statementName[?options]
Where statementName is the statement name in the MyBatis XML mapping file which maps to the query, insert, update or delete operation you wish to evaluate.
You can append query options to the URI in the following format, ?option=value&option=value&...
This component will by default load the MyBatis SqlMapConfig file from the root of the classpath and expected named as SqlMapConfig.xml.
If the file is located in another location, you would have to configure the configurationUri option on the MyBatisComponent component.
| Option | Type | Default | Description |
|---|---|---|---|
consumer.onConsume
|
String
|
null
|
Statements to run after consuming. Can be used, for example, to update rows after they have been consumed and processed in Camel. See sample later. Multiple statements can be separated with comma. |
consumer.useIterator
|
boolean
|
true
|
If true each row returned when polling will be processed individually. If false the entire List of data is set as the IN body. |
consumer.routeEmptyResultSet
|
boolean
|
false
|
Sets whether empty result set should be routed or not. By default, empty result sets are not routed. |
statementType
|
StatementType
|
null
|
Mandatory to specify for producer to control which kind of operation to invoke. The enum values are: SelectOne, SelectList, Insert, Update, Delete. |
maxMessagesPerPoll
|
int
|
0
|
An integer to define a maximum messages to gather per poll. By default, no maximum is set. Can be used to set a limit of e.g. 1000 to avoid when starting up the server that there are thousands of files. Set a value of 0 or negative to disabled it. |
Camel will populate the result message, either IN or OUT with a header with the statement used:
| Header | Type | Description |
|---|---|---|
CamelMyBatisStatementName
|
String
|
The statementName used (for example: insertAccount). |
CamelMyBatisResult
|
Object
|
The response returned from MtBatis in any of the operations. For instance an INSERT could return the auto-generated key, or number of rows etc. |
The response from MyBatis will only be set as body if it's a SELECT statement. That means, for example, for INSERT statements Camel will not replace the body. This allows you to continue routing and keep the original body. The response from MyBatis is always stored in the header with the key CamelMyBatisResult.
For example if you wish to consume beans from a JMS queue and insert them into a database you could do the following:
from("activemq:queue:newAccount").
to("mybatis:insertAccount?statementType=Insert");
Notice we have to specify the statementType, as we need to instruct Camel which kind of operation to invoke.
Where insertAccount is the MyBatis ID in the SQL mapping file:
<!-- Insert example, using the Account parameter class -->
<insert id="insertAccount" parameterType="Account">
insert into ACCOUNT (
ACC_ID,
ACC_FIRST_NAME,
ACC_LAST_NAME,
ACC_EMAIL
)
values (
#{id}, #{firstName}, #{lastName}, #{emailAddress}
)
</insert>
When routing to an MyBatis endpoint you want more fine grained control so you can control whether the SQL statement to be executed is a SELEECT, UPDATE, DELETE or INSERT etc. So for instance if we want to route to an MyBatis endpoint in which the IN body contains parameters to a SELECT statement we can do:
from("direct:start")
.to("mybatis:selectAccountById?statementType=SelectOne")
.to("mock:result");
In the code above we can invoke the MyBatis statement selectAccountById and the IN body should contain the account id we want to retrieve, such as an Integer type.
We can do the same for some of the other operations, such as SelectList:
from("direct:start")
.to("mybatis:selectAllAccounts?statementType=SelectList")
.to("mock:result");
And the same for UPDATE, where we can send an Account object as IN body to MyBatis:
from("direct:start")
.to("mybatis:updateAccount?statementType=Update")
.to("mock:result");
Since this component does not support scheduled polling, you need to use another mechanism for triggering the scheduled polls, such as the Timer or Quartz components.
In the sample below we poll the database, every 30 seconds using the Timer component and send the data to the JMS queue:
from("timer://pollTheDatabase?delay=30000").to("mbatis:selectAllAccounts").to("activemq:queue:allAccounts");
And the MyBatis SQL mapping file used:
<!-- Select with no parameters using the result map for Account class. -->
<select id="selectAllAccounts" resultMap="AccountResult">
select * from ACCOUNT
</select>
This component supports executing statements after data have been consumed and processed by Camel. This allows you to do post updates in the database. Notice all statements must be UPDATE statements. Camel supports executing multiple statements whose name should be separated by comma.
The route below illustrates we execute the consumeAccount statement data is processed. This allows us to change the status of the row in the database to processed, so we avoid consuming it twice or more.
from("mybatis:selectUnprocessedAccounts?consumer.onConsume=consumeAccount").to("mock:results");
And the statements in the sqlmap file:
<select id="selectUnprocessedAccounts" resultMap="AccountResult">
select * from ACCOUNT where PROCESSED = false
</select>
<update id="consumeAccount" parameterType="Account">
update ACCOUNT set PROCESSED = true where ACC_ID = #{id}
</update>
The Nagios component allows you to send passive checks to Nagios.
nagios://host[:port][?Options]
Apache Camel provides two abilities with the Nagios component. You can send passive check messages by sending a message to its endpoint. Apache Camel also provides a EventNotifer which allows you to send notifications to Nagios.
| Name | Default Value | Description |
|---|---|---|
host
|
none | This is the address of the Nagios host where checks should be send. |
port
|
The port number of the host. | |
password
|
Password to be authenticated when sending checks to Nagios. | |
connectionTimeout
|
5000 | Connection timeout in millis. |
timeout
|
5000 | Sending timeout in millis. |
nagiosSettings
|
To use an already configured
com.googlecode.jsendnsca.core.NagiosSettings object. |
|
sendSync
|
true
|
Whether or not to use synchronous when sending a passive check. Setting it to
false will allow Apache Camel to continue routing the message and the
passive check message will be send asynchronously. |
| Name | Description |
|---|---|
CamelNagiosHostName
|
This is the address of the Nagios host where checks should be send. This header will override any existing hostname configured on the endpoint. |
CamelNagiosLevel
|
This is the severity level. You can use values CRITICAL, WARNING,
OK. Apache Camel will by default use OK. |
CamelNagiosServiceName
|
The servie name. Will default use the CamelContext
name. |
You can send a message to Nagios where the message payload contains the message. By
default it will be OK level and use the CamelContext name as the service name. You can overrule these values using headers
as shown above.
For example we send the Hello Nagios message to Nagios as
follows:
template.sendBody("direct:start", "Hello Nagios");
from("direct:start").to("nagios:127.0.0.1:5667?password=secret").to("mock:result");To send a CRITICAL message you can send the headers such as:
Map headers = new HashMap();
headers.put(NagiosConstants.LEVEL, "CRITICAL");
headers.put(NagiosConstants.HOST_NAME, "myHost");
headers.put(NagiosConstants.SERVICE_NAME, "myService");
template.sendBodyAndHeaders("direct:start", "Hello Nagios", headers);The Nagios component also provides an EventNotifer which you can use to send events to Nagios. For example we can enable this from Java as follows:
NagiosEventNotifier notifier = new NagiosEventNotifier();
notifier.getConfiguration().setHost("localhost");
notifier.getConfiguration().setPort(5667);
notifier.getConfiguration().setPassword("password");
CamelContext context = ...
context.getManagementStrategy().addEventNotifier(notifier);
return context;
In Spring XML its just a matter of defining a Spring bean with the type
EventNotifier and Apache Camel will pick it up as documented here: Advanced configuration of
CamelContext using Spring.
The netty component in Apache Camel is a socket communication component, based on the JBoss Netty community offering (available under an Apache 2.0 license). Netty is a NIO client server framework which enables quick and easy development of network applications such as protocol servers and clients. Netty greatly simplifies and streamlines network programming such as TCP and UDP socket server.
This Apache Camel component supports both producer and consumer endpoints.
The netty component has several options and allows fine-grained control of a number of TCP/UDP communication parameters (buffer sizes, keepAlives, tcpNoDelay etc) and facilitates both In-Only and In-Out communication on a Apache Camel route.
The URI scheme for a netty component is as follows
netty:tcp://localhost:99999[?options] netty:udp://remotehost:99999/[?options]
This component supports producer and consumer endpoints for both TCP and UDP.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
keepAlive
|
true
|
Setting to ensure socket is not closed due to inactivity |
tcpNoDelay
|
true
|
Setting to improve TCP protocol performance |
broadcast
|
false
|
Setting to choose Multicast over UDP |
connectTimeout
|
10000
|
Time to wait for a socket connection to be available. Value is in millis. |
reuseAddress
|
true
|
Setting to facilitate socket multiplexing |
sync
|
true
|
Setting to set endpoint as one-way or request-response |
ssl
|
false
|
Setting to specify whether SSL encryption is applied to this endpoint |
sendBufferSize
|
65536 bytes
|
The TCP/UDP buffer sizes to be used during outbound communication. Size is bytes. |
receiveBufferSize
|
65536 bytes
|
The TCP/UDP buffer sizes to be used during inbound communication. Size is bytes. |
corePoolSize
|
10
|
The number of allocated threads at component startup. Defaults to 10 |
maxPoolSize
|
100
|
The maximum number of threads that may be allocated to this endpoint. Defaults to 100 |
disconnect
|
false
|
Whether or not to disconnect(close) from Netty Channel right after use. Can be used for both consumer and producer. |
lazyChannelCreation
|
true
|
Channels can be lazily created to avoid exceptions, if the remote server is not up and running when the Apache Camel producer is started. |
transferExchange
|
false
|
Only used for TCP. You can transfer the exchange over the wire instead of just the body. The following fields are transferred: In body, Out body, fault body, In headers, Out headers, fault headers, exchange properties, exchange exception. This requires that the objects are serializable. Apache Camel will exclude any non-serializable objects and log it at WARN level. |
disconnectOnNoReply
|
true
|
If sync is enabled then this option dictates NettyConsumer if it should disconnect where there is no reply to send back. |
noReplyLogLevel
|
WARN
|
If sync is enabled this option dictates NettyConsumer which logging level to use when
logging a there is no reply to send back. Values are: FATAL, ERROR, INFO, DEBUG,
OFF. |
allowDefaultCodec
|
true
|
Camel 2.4: The netty component installs a default codec if both, encoder/deocder is null and textline is false. Setting allowDefaultCodec to false prevents the netty component from installing a default codec as the first element in the filter chain. |
textline
|
false
|
Camel 2.4: Only used for TCP. If no codec is specified, you can use this flag to indicate a text line based codec; if not specified or the value is false, then Object Serialization is assumed over TCP. |
delimiter
|
LINE
|
Camel 2.4: The delimiter to use for the textline codec.
Possible values are LINE and NULL. |
decoderMaxLineLength
|
1024
|
Camel 2.4: The max line length to use for the textline codec. |
autoAppendDelimiter
|
true
|
Camel 2.4: Whether or not to auto append missing end delimiter when sending using the textline codec. |
encoding
|
null
|
Camel 2.4: The encoding (a charset name) to use for the textline codec. If not provided, Camel will use the JVM default Charset. |
Codec Handlers and SSL Keystores can be enlisted in the Registry, such as in the Spring XML file. The values that could be passed in, are the following:
| Name | Description |
|---|---|
passphrase
|
password setting to use in order to encrypt/decrypt payloads sent using SSH |
keyStoreFormat
|
keystore format to be used for payload encryption. Defaults to "JKS" if not set |
securityProvider
|
Security provider to be used for payload encryption. Defaults to "SunX509" if not set. |
keyStoreFile
|
Client side certificate keystore to be used for encryption |
trustStoreFile
|
Server side certificate keystore to be used for encryption |
sslHandler
|
Reference to a class that could be used to return an SSL Handler |
encoder
|
A custom Handler class that can be used to perform special marshalling of outbound
payloads. Must override
org.jboss.netty.channel.ChannelDownStreamHandler. |
encorders
|
A list of encoder to be used. You can use a String which have values separated by comma, and have the values be looked up in the Registry. Just remember to prefix the value with # so Apache Camel knows it should lookup. |
decoder
|
A custom Handler class that can be used to perform special marshalling of inbound
payloads. Must override org.jboss.netty.channel.ChannelUpStreamHandler.
|
decoders
|
A list of decorder to be used. You can use a String which have values separated by comma, and have the values be looked up in the Registry. Just remember to prefix the value with # so Apache Camel knows it should lookup. |
In Producer mode, the component provides the ability to send payloads to a socket endpoint using either TCP or UDP protocols (with optional SSL support).
The producer mode supports both one-way and request-response based operations.
In Consumer mode, the component provides the ability to:
listen on a specified socket using either TCP or UDP protocols (with optional SSL support),
receive requests on the socket using text/xml, binary and serialized object based payloads and
send them along on a route as message exchanges.
The consumer mode supports both one-way and request-response based operations.
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("netty:udp://localhost:5155?sync=true")
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
Poetry poetry = (Poetry) exchange.getIn().getBody();
poetry.setPoet("Dr. Sarojini Naidu");
exchange.getOut().setBody(poetry);
}
}
}
};RouteBuilder builder = new RouteBuilder() {
public void configure() {
from("netty:tcp://localhost:5150")
.to("mock:result");
}
};JndiRegistry registry = new JndiRegistry(createJndiContext());
registry.bind("password", "changeit");
registry.bind("ksf", new File("src/test/resources/keystore.jks"));
registry.bind("tsf", new File("src/test/resources/keystore.jks"));
context.createRegistry(registry);
context.addRoutes(new RouteBuilder() {
public void configure() {
String netty_ssl_endpoint =
"netty:tcp://localhost:5150?sync=true&ssl=true&passphrase=#password"
+ "&keyStoreFile=#ksf&trustStoreFile=#tsf";
String return_string =
"When You Go Home, Tell Them Of Us And Say,"
+ "For Your Tomorrow, We Gave Our Today.";
from(netty_ssl_endpoint)
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
exchange.getOut().setBody(return_string);
}
}
}
});In certain cases it may be necessary to add chains of encoders and decoders to the netty pipeline. To add multpile codecs to a Apache Camel netty endpoint the 'encoders' and 'decoders' uri parameters should be used. Like the 'encoder' and 'decoder' parameters they are used to supply references (to lists of ChannelUpstreamHandlers and ChannelDownstreamHandlers) that should be added to the pipeline. Note that if encoders is specified then the encoder param will be ignored, similarly for decoders and the decoder param.
The lists of codecs need to be added to the Apache Camel's registry so they can be resolved when the endpoint is created.
LengthFieldBasedFrameDecoder lengthDecoder = new LengthFieldBasedFrameDecoder(1048576, 0, 4, 0, 4);
StringDecoder stringDecoder = new StringDecoder();
registry.bind("length-decoder", lengthDecoder);
registry.bind("string-decoder", stringDecoder);
LengthFieldPrepender lengthEncoder = new LengthFieldPrepender(4);
StringEncoder stringEncoder = new StringEncoder();
registry.bind("length-encoder", lengthEncoder);
registry.bind("string-encoder", stringEncoder);
List<ChannelUpstreamHandler> decoders = new ArrayList<ChannelUpstreamHandler>();
decoders.add(lengthDecoder);
decoders.add(stringDecoder);
List<ChannelDownstreamHandler> encoders = new ArrayList<ChannelDownstreamHandler>();
encoders.add(lengthEncoder);
encoders.add(stringEncoder);
registry.bind("encoders", encoders);
registry.bind("decoders", decoders);Spring's native collections support can be used to specify the codec lists in an application context
<util:list id="decoders" list-class="java.util.LinkedList">
<bean class="org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder">
<constructor-arg value="1048576"/>
<constructor-arg value="0"/>
<constructor-arg value="4"/>
<constructor-arg value="0"/>
<constructor-arg value="4"/>
</bean>
<bean class="org.jboss.netty.handler.codec.string.StringDecoder"/>
</util:list>
<util:list id="encoders" list-class="java.util.LinkedList">
<bean class="org.jboss.netty.handler.codec.frame.LengthFieldPrepender">
<constructor-arg value="4"/>
</bean>
<bean class="org.jboss.netty.handler.codec.string.StringEncoder"/>
</util:list>
<bean id="length-encoder" class="org.jboss.netty.handler.codec.frame.LengthFieldPrepender">
<constructor-arg value="4"/>
</bean>
<bean id="string-encoder" class="org.jboss.netty.handler.codec.string.StringEncoder"/>
<bean id="length-decoder" class="org.jboss.netty.handler.codec.frame.LengthFieldBasedFrameDecoder">
<constructor-arg value="1048576"/>
<constructor-arg value="0"/>
<constructor-arg value="4"/>
<constructor-arg value="0"/>
<constructor-arg value="4"/>
</bean>
<bean id="string-decoder" class="org.jboss.netty.handler.codec.string.StringDecoder"/>
</beans>The bean names can then be used in netty endpoint definitions either as a comma separated list or contained in a List e.g.
<camelContext id="multiple-netty-codecs-context" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:multiple-codec"/>
<to uri="netty:tcp://localhost:5150?encoders=#encoders&ync=false"/>
</route>
<route>
<from uri="netty:tcp://localhost:5150?decoders=#length-decoder,#string-decoder&ync=false"/>
<to uri="mock:multiple-codec"/>
</route>
</camelContext>When acting as a server you sometimes want to close the channel when, for example, a
client conversion is finished. You can do this by simply setting the endpoint option
disconnect=true.
However you can also instruct Apache Camel on a per message basis as follows. To instruct
Apache Camel to close the channel, you should add a header with the key
CamelNettyCloseChannelWhenComplete set to a boolean
true value. For instance, the example below will close the channel after
it has written the bye message back to the client:
from("netty:tcp://localhost:8080").process(new Processor() {
public void process(Exchange exchange) throws Exception {
String body = exchange.getIn().getBody(String.class);
exchange.getOut().setBody("Bye " + body);
// some condition which determines if we should close
if (close) {
exchange.getOut().setHeader(NettyConstants.NETTY_CLOSE_CHANNEL_WHEN_COMPLETE, true);
}
}
});Available as of Camel 2.5
Custom channel pipelines provide complete control to the user over the handler/interceptor chain by inserting custom handler(s), encoder(s) and decoders without having to specify them in the Netty Endpoint URL in a very simple way.
In order to add a custom pipeline, a custom channel pipeline factory must be created and
registered with the context through the context registry (JNDIRegistry,or the
Spring ApplicationContextRegistry etc).
A custom pipeline factory must be constructed as follows
A Producer linked channel pipeline factory must extend the abstract class,
ClientPipelineFactory.
A Consumer linked channel pipeline factory must extend the abstract class,
ServerPipelineFactory.
The classes can optionally override the getPipeline() method in order to
insert custom handler(s), encoder(s) and decoder(s). Not overriding the
getPipeline() method creates a pipeline with no handlers, encoders or
decoders wired to the pipeline.
The example below shows how ServerChannel Pipeline factory may be created
public class SampleServerChannelPipelineFactory extends ServerPipelineFactory {
private int maxLineSize = 1024;
private boolean invoked;
public ChannelPipeline getPipeline() throws Exception {
invoked = true;
ChannelPipeline channelPipeline = Channels.pipeline();
channelPipeline.addLast("encoder-SD", new StringEncoder(CharsetUtil.UTF_8));
channelPipeline.addLast("decoder-DELIM", new DelimiterBasedFrameDecoder(maxLineSize, true, Delimiters.lineDelimiter()));
channelPipeline.addLast("decoder-SD", new StringDecoder(CharsetUtil.UTF_8));
channelPipeline.addLast("handler", new ServerChannelHandler(consumer));
return channelPipeline;
}
public boolean isfactoryInvoked() {
return invoked;
}
}The custom channel pipeline factory can then be added to the registry and instantiated/utilized on a camel route as follows:
Registry registry = camelContext.getRegistry();
serverPipelineFactory = new TestServerChannelPipelineFactory();
registry.bind("spf", serverPipelineFactory);
context.addRoutes(new RouteBuilder() {
public void configure() {
String netty_ssl_endpoint =
"netty:tcp://localhost:5150?serverPipelineFactory=#spf";
String return_string =
"When You Go Home, Tell Them Of Us And Say,"
+ "For Your Tomorrow, We Gave Our Today.";
from(netty_ssl_endpoint)
.process(new Processor() {
public void process(Exchange exchange) throws Exception {
exchange.getOut().setBody(return_string);
}
}
}
});The nmr component is an adapter to the Normalized Message Router (NMR) in ServiceMix, which is intended for use by Apache Camel applications deployed directly into the OSGi container. By contrast, the JBI component is intended for use by Apache Camel applications deployed into the ServiceMix JBI container.
The NMR component is provided with Apache ServiceMix. It is not distributed with Apache Camel. To install the NMR component in ServiceMix, enter the following command in the ServiceMix console window:
features install nmr
You also need to instantiate the NMR component. You can do this by editing your Spring
configuration file, META-INF/spring/*.xml, and adding the following
bean instance:
<beans xmlns:osgi="http://www.springframework.org/schema/osgi" ... >
...
<bean id="nmr" class="org.apache.servicemix.camel.nmr.ServiceMixComponent">
<property name="nmr">
<osgi:reference interface="org.apache.servicemix.nmr.api.NMR" />
</property>
</bean>
...
</beans>The following code:
from("nmr:MyServiceEndpoint")Automatically exposes a new endpoint to the bus with endpoint name
MyServiceEndpoint (see URI format).
When an NMR endpoint appears at the end of a route, for example:
to("nmr:MyServiceEndpoint")The messages sent by this producer endpoint are sent to the already deployed JBI endpoint.
| Option | Default Value | Description |
|---|---|---|
synchronous
|
false
|
When this is set to true on
a consumer endpoint, an incoming, synchronous NMR Exchange will be handled on
the sender's thread instead of being handled on a new thread of the NMR
endpoint's thread pool |
from("nmr:MyServiceEndpoint")
from("nmr:MyServiceEndpoint?synchronous=true").to("nmr:AnotherEndpoint")If you are using a stream type as the message body, you should be aware that a stream
is only capable of being read once. So if you enable DEBUG logging,
the body is usually logged and thus read. To deal with this, Camel has a
streamCaching option that can cache the stream, enabling you to
read it multiple times.
from("nmr:MyEndpoint").streamCaching().to("xslt:transform.xsl", "bean:doSomething");
From Camel 1.5 onwards, the stream caching is default
enabled, so it is not necessary to set the streamCaching() option. In
Camel 2.0 we store big input streams (by default,
over 64K) in a temp file using CachedOutputStream.
When you close the input stream, the temp file will be deleted.
Available as of Apache Camel 2.1
The printer component provides a way to direct payloads on a route to a printer. Obviously the payload has to be a formatted piece of payload in order for the component to appropriately print it. The objective is to be able to direct specific payloads as jobs to a line printer in a Apache Camel flow.
This component only supports a producer endpoint.
The functionality allows for the payload to be printed on a default printer, named local, remote or wirelessly linked printer using the javax printing API under the covers.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-printer</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
Since the URI scheme for a printer has not been standardized (the nearest thing to a standard being the IETF print standard) and therefore not uniformly applied by vendors, we have chosen "lpr" as the scheme.
lpr://localhost/default[?options] lpr://remotehost:port/path/to/printer[?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
mediaSize
|
MediaSizeName.NA_LETTER
|
Sets the stationary as defined by enumeration settings in the
javax.print.attribute.standard.MediaSizeName API. The default
setting is to use North American Letter sized stationary |
copies
|
1
|
Sets number of copies based on the
javax.print.attribute.standard.Copies API |
sides
|
Sides.ONE_SIDED
|
Sets one sided or two sided printing based on the
javax.print.attribute.standard.Sides API |
flavor
|
DocFlavor.BYTE_ARRAY
|
Sets DocFlavor based on the javax.print.DocFlavor API
|
mimeType
|
AUTOSENSE
|
Sets mimeTypes supported by the javax.print.DocFlavor
API |
Sending data to the printer is very straightforward and involves creating a producer endpoint that can be sent message exchanges on in route.
RouteBuilder builder = new RouteBuilder() {
public void configure() {
from(file://inputdir/?delete=true)
.to("lpr://localhost/default?copies=2" +
"&flavor=DocFlavor.INPUT_STREAM&" +
"&mimeType=AUTOSENSE" +
"&mediaSize=na-letter" +
"&sides=one-sided")
}};RouteBuilder builder = new RouteBuilder() {
public void configure() {
from(file://inputdir/?delete=true)
.to("lpr://remotehost/sales/salesprinter" +
"?copies=2&sides=one-sided" +
"&mimeType=GIF&mediaSize=iso-a4" +
"&flavor=DocFlavor.INPUT_STREAM")
}};RouteBuilder builder = new RouteBuilder() {
public void configure() {
from(file://inputdir/?delete=true)
.to("lpr://remotehost/sales/salesprinter" +
"?copies=2&sides=one-sided" +
"&mimeType=JPEG" +
"&mediaSize=japanese-postcard" +
"&flavor=DocFlavor.INPUT_STREAM")
}};Property endpoints allow you to resolve the address for the endpoint using a property placeholder. Property placeholders can be created using a properties file, OSGi properties, the OSGi registry, Spring beans, or as part of the route definition.
The URI format for a property endpoint is:
properties:key[?options]
Where key is the key for the property to lookup.
Table 52.1 describes the options for a property endpoint.
Table 52.1. Properties options
| Name | Default | Description |
|---|---|---|
cache | true | Specifies whether to cache loaded properties. |
locations | Specifies a list of locations from which to load properties. A comma separated
list is use to specify multiple locations. This option will override any locations
specified in the camelContext or the
configuration. |
The quickfix component adapts the QuickFIX/J FIX engine for using in Camel . This component uses the standard Financial Interchange (FIX) protocol for message transport.
| Previous Versions |
|---|---|
The quickfix component was rewritten for Camel 2.5. For information about using the quickfix component prior to 2.5 see the documentation section below. |
Maven users will need to add the following dependency to their pom.xml
for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-quickfix</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>quickfix:configFile[?sessionID=sessionID]
The configFile is the name of the QuickFIX/J configuration to use for the FIX engine (located as a resource found in your classpath). The optional sessionID identifies a specific FIX session. The format of the sessionID is:
(BeginString):(SenderCompID)[/(SenderSubID)[/(SenderLocationID)]]->(TargetCompID)[/(TargetSubID)[/(TargetLocationID)]]
Example URIs:
quickfix:config.cfg quickfix:config.cfg?sessionID=FIX.4.2:MyTradingCompany->SomeExchange
FIX sessions are endpoints for the quickfix component. An endpoint URI may specify a single session or all sessions managed by a specific QuickFIX/J engine. Typical applications will use only one FIX engine but advanced users may create multiple FIX engines by referencing different configuration files in quickfix component endpoint URIs.
When a consumer does not include a session ID in the endpoint URI, it will receive exchanges for all sessions managed by the FIX engine associated with the configuration file specified in the URI. If a producer does not specify a session in the endpoint URI then it must include the session-related fields in the FIX message being sent. If a session is specified in the URI then the component will automatically inject the session-related fields into the FIX message.
The exchange headers include information to help with exchange filtering, routing and other processing. The following headers are available:
| Header Name | Description |
|---|---|
EventCategory
|
One of AppMessageReceived, AppMessageSent,
AdminMessageReceived, AdminMessageSent,
SessionCreated, SessionLogon,
SessionLogoff. See the QuickfixjEventCategory
enum. |
SessionID
|
The FIX message SessionID |
MessageType
|
The FIX MsgType tag value |
DataDictionary
|
Specifies a data dictionary to used for parsing an incoming message. Can be an instance of a data dictionary or a resource path for a QuickFIX/J data dictionary file |
The DataDictionary header is useful if string messages are being received and need to be parsed in a route. QuickFIX/J requires a data dictionary to parse certain types of messages (with repeating groups, for example). By injecting a DataDictionary header in the route after receiving a message string, the FIX engine can properly parse the data.
When using QuickFIX/J directly, one typically writes code to create instances of logging adapters, message stores and communication connectors. The quickfix component will automatically create instances of these classes based on information in the configuration file. It also provides defaults for many of the common required settings and adds additional capabilities (like the ability to activate JMX support).
The following sections describe how the quickfix component processes the QuickFIX/J configuration. For comprehensive information about QuickFIX/J configuration, see the QFJ user manual.
When the component detects an initiator or acceptor session setting in the QuickFIX/J configuration file it will automatically create the corresponding initiator and/or acceptor connector. These settings can be in the default or in a specific session section of the configuration file.
| Session Setting | Component Action |
|---|---|
ConnectionType=initiator
|
Create an initiator connector |
ConnectionType=acceptor
|
Create an acceptor connector |
The threading model for the QuickFIX/J session connectors can also be specified. These settings affect all sessions in the configuration file and must be placed in the settings default section.
| Default/Global Setting | Component Action |
|---|---|
ThreadModel=ThreadPerConnector
|
Use SocketInitiator or SocketAcceptor (default)
|
ThreadModel=ThreadPerSession
|
Use ThreadedSocketInitiator or
ThreadedSocketAcceptor
|
The QuickFIX/J logger implementation can be specified by including the following settings
in the default section of the configuration file. The ScreenLog is the
default if none of the following settings are present in the configuration. It's an error to
include settings that imply more than one log implementation.
| Default/Global Setting | Component Action |
|---|---|
ScreenLogShowEvents
|
Use a ScreenLog
|
ScreenLogShowIncoming
|
Use a ScreenLog
|
ScreenLogShowOutgoing
|
Use a ScreenLog
|
SLF4J*
|
Camel 2.6+. Use a SLF4JLog. Any of
the SLF4J settings will cause this log to be used. |
FileLogPath
|
Use a FileLog
|
JdbcDriver
|
Use a JdbcLog
|
The QuickFIX/J message store implementation can be specified by including the following
settings in the default section of the configuration file. The MemoryStore
is the default if none of the following settings are present in the configuration. It's an
error to include settings that imply more than one message store implementation.
| Default/Global Setting | Component Action |
|---|---|
JdbcDriver
|
Use a JdbcStore
|
FileStorePath
|
Use a FileStore
|
SleepycatDatabaseDir
|
Use a SleepcatStore
|
A message factory is used to construct domain objects from raw FIX messages. The default
message factory is DefaultMessageFactory. However, advanced applications
may require a custom message factory. This can be set on the QuickFIX/J component.
The component provides some default settings for what are normally required settings in
QuickFIX/J configuration files. SessionStartTime and
SessionEndTime default to "00:00:00", meaning the session will not be
automatically started and stopped. The HeartBtInt (heartbeat interval)
defaults to 30 seconds.
[SESSION] ConnectionType=initiator BeginString=FIX.4.4 SenderCompID=YOUR_SENDER TargetCompID=YOUR_TARGET
QuickFIX/J behavior can be modified if certain exceptions are thrown during processing of
a message. If a RejectLogon exception is thrown while processing an
incoming logon administrative message, then the logon will be rejected.
Normally, QuickFIX/J handles the logon process automatically. However, sometimes an outgoing logon message must be modified to include credentials required by a FIX counterparty. If the FIX logon message body is modified when sending a logon message (EventCategory={{AdminMessageSent}} the modified message will be sent to the counterparty. It is important that the outgoing logon message is being processed synchronously. If it is processed asynchronously (on another thread), the FIX engine will immediately send the unmodified outgoing message when it's callback method returns.
If an application exception is thrown during synchronous exchange processing, this will cause QuickFIX/J to not increment incoming FIX message sequence numbers and will cause a resend of the counterparty message. This FIX protocol behavior is primarily intended to handle transport errors rather than application errors. There are risks associated with using this mechanism to handle application errors. The primary risk is that the message will repeatedly cause application errors each time it's re-received. A better solution is to persist the incoming message (database, JMS queue) immediately before processing it. This also allows the application to process messages asynchronously without losing messages when errors occur.
Although it's possible to send messages to a FIX session before it's logged on (the
messages will be sent at logon time), it is usually a better practice to wait until the
session is logged on. This eliminates the required sequence number resynchronization steps at
logon. Waiting for session logon can be done by setting up a route that processes the
SessionLogon event category and signals the application to start sending
messages.
See the FIX protocol specifications and the QuickFIX/J documentation for more details about FIX sequence number management.
Several examples are included in the QuickFIX/J component source code (test subdirectories). One of these examples implements a trival trade excecution simulation. The example defines an application component that uses the URI scheme "trade-executor".
The following route receives messages for the trade executor session and passes application messages to the trade executor component.
from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:MARKET->TRADER").
filter(header(QuickfixjEndpoint.EVENT_CATEGORY_KEY).isEqualTo(QuickfixjEventCategory.AppMessageReceived)).
to("trade-executor:market");The trade executor component generates messages that are routed back to the trade session. The session ID must be set in the FIX message itself since no session ID is specified in the endpoint URI.
from("trade-executor:market").to("quickfix:examples/inprocess.cfg");The trader session consumes execution report messages from the market and processes them.
from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:TRADER->MARKET").
filter(header(QuickfixjEndpoint.MESSAGE_TYPE_KEY).isEqualTo(MsgType.EXECUTION_REPORT)).
bean(new MyTradeExecutionProcessor());The ref: component is used for lookup of existing endpoints bound in the Registry.
ref:someName
Where someName is the name of an endpoint in the Registry (usually, but not always, the Spring registry). If you
are using the Spring registry, someName would be the bean ID of an endpoint
in the Spring registry.
This component can be used when you need dynamic discovery of endpoints in the Registry where you can compute the URI at runtime. Then you can look up the endpoint using the following code:
// lookup the endpoint
String myEndpointRef = "bigspenderOrder";
Endpoint endpoint = context.getEndpoint("ref:" + myEndpointRef);
Producer producer = endpoint.createProducer();
Exchange exchange = producer.createExchange();
exchange.getIn().setBody(payloadToSend);
// send the exchange
producer.process(exchange);
...And you could have a list of endpoints defined in the Registry such as:
<camelContext id="camel" xmlns="http://activemq.apache.org/camel/schema/spring">
<endpoint id="normalOrder" uri="activemq:order.slow"/>
<endpoint id="bigspenderOrder" uri="activemq:order.high"/>
...
</camelContext>In the sample below we use the ref: in the URI to reference the
endpoint with the Spring ID, endpoint2:
<bean id="mybean" class="org.apache.camel.spring.example.DummyBean">
<property name="endpoint" ref="endpoint1"/>
</bean>
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<jmxAgent id="agent" disabled="true"/>
<endpoint id="endpoint1" uri="direct:start"/>
<endpoint id="endpoint2" uri="mock:end"/>
<route>
<from ref="endpoint1"/>
<to uri="ref:endpoint2"/>
</route>
</camelContext>You could, of course, have used the ref attribute instead:
<to ref="endpoint2"/>
Which is the more common way to write it.
Available as of Camel 2.6
| Routebox subject to change |
|---|---|
The Routebox component will be revisited in upcoming releases to see if it can be further simplified, be more intuitive and user friendly. The related Context component may be regarded as the simpler component. This component might be deprecated in favor of Context. |
The routebox component enables the creation of specialized endpoints that offer encapsulation and a strategy based indirection service to a collection of camel routes hosted in an automatically created or user injected camel context.
Routebox endpoints are camel endpoints that may be invoked directly on camel routes. The routebox endpoint performs the following key functions * encapsulation - acts as a blackbox, hosting a collection of camel routes stored in an inner camel context. The inner context is fully under the control of the routebox component and is JVM bound. * strategy based indirection - direct payloads sent to the routebox endpoint along a camel route to specific inner routes based on a user defined internal routing strategy or a dispatch map. * exchange propagation - forward exchanges modified by the routebox endpoint to the next segment of the camel route.
The routebox component supports both consumer and producer endpoints.
Producer endpoints are of two flavors * Producers that send or dispatch incoming requests to a external routebox consumer endpoint * Producers that directly invoke routes in an internal embedded camel context thereby not sending requests to an external consumer.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-routebox</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
The routebox component is designed to ease integration in complex environments needing * a large collection of routes and * involving a wide set of endpoint technologies needing integration in different ways
In such environments, it is often necessary to craft an integration solution by creating a sense of layering among camel routes effectively organizing them into * Coarse grained or higher level routes - aggregated collection of inner or lower level routes exposed as Routebox endpoints that represent an integration focus area. For example ||Focus Area||Coarse grained Route Examples|| |Department Focus|HR routes, Sales routes etc| |Supply chain & B2B Focus|Shipping routes, Fulfillment routes, 3rd party services etc| |Technology Focus|Database routes, JMS routes, Scheduled batch routes etc| * Fine grained routes - routes that execute a singular and specific business and/or integration pattern.
Requests sent to Routebox endpoints on coarse grained routes can then delegate requests to inner fine grained routes to achieve a specific integration objective, collect the final inner result, and continue to progress to the next step along the coarse-grained route.
routebox:routeboxname[?options]
You can append query options to the URI in the following format, ?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
dispatchStrategy
|
null
|
A string representing a key in the Camel Registry matching an object value implementing the interface org.apache.camel.component.routebox.strategy.RouteboxDispatchStrategy |
dispatchMap
|
null
|
A string representing a key in the Camel Registry matching an object value of the type HashMap<String, String>. The HashMap key should contain strings that can be matched against the value set for the exchange header ROUTE_DISPATCH_KEY. The HashMap value should contain inner route consumer URI's to which requests should be directed. |
innerContext
|
auto created
|
A string representing a key in the Camel Registry matching an object value of the type org.apache.camel.CamelContext. If a CamelContext is not provided by the user a CamelContext is automatically created for deployment of inner routes. |
innerRegistry
|
null
|
A string representing a key in the Camel Registry matching an object value that implements the interface org.apache.camel.spi.Registry. If Registry values are utilized by inner routes to create endpoints, an innerRegistry parameter must be provided |
routeBuilders
|
empty List
|
A string representing a key in the Camel Registry matching an object value of the type List<org.apache.camel.builder.RouteBuilder>. If the user does not supply an innerContext pre-primed with inner routes, the routeBuilders option must be provided as a non-empty list of RouteBuilders containing inner routes |
innerProtocol
|
Direct
|
The Protocol used internally by the Routebox component. Can be Direct or SEDA. The Routebox component currently offers protocols that are JVM bound. |
sendToConsumer
|
true
|
Dictates whether a Producer endpoint sends a request to an external routebox consumer. If the setting is false, the Producer creates an embedded inner context and processes requests internally. |
forkContext
|
true
|
The Protocol used internally by the Routebox component. Can be Direct or SEDA. The Routebox component currently offers protocols that are JVM bound. |
threads
|
20
|
Number of threads to be used by the routebox to receive requests. Setting applicable only for innerProtocol SEDA. |
queueSize
|
unlimited
|
Create a fixed size queue to receive requests. Setting applicable only for innerProtocol SEDA. |
Before sending requests it is necessary to properly configure the routebox by loading the required URI parameters into the Registry as shown below. In the case of Spring, if the necessary beans are declared correctly, the registry is automatically populated by Camel.
@Override
protected JndiRegistry createRegistry() throws Exception {
JndiRegistry registry = new JndiRegistry(createJndiContext());
// Wire the routeDefinitions & dispatchStrategy to the outer camelContext where the routebox is declared
List<RouteBuilder> routes = new ArrayList<RouteBuilder>();
routes.add(new SimpleRouteBuilder());
registry.bind("registry", createInnerRegistry());
registry.bind("routes", routes);
// Wire a dispatch map to registry
HashMap<String, String> map = new HashMap<String, String>();
map.put("addToCatalog", "seda:addToCatalog");
map.put("findBook", "seda:findBook");
registry.bind("map", map);
// Alternatively wiring a dispatch strategy to the registry
registry.bind("strategy", new SimpleRouteDispatchStrategy());
return registry;
}
private JndiRegistry createInnerRegistry() throws Exception {
JndiRegistry innerRegistry = new JndiRegistry(createJndiContext());
BookCatalog catalogBean = new BookCatalog();
innerRegistry.bind("library", catalogBean);
return innerRegistry;
}
...
CamelContext context = new DefaultCamelContext(createRegistry());
Using a dispatch Strategy involves implementing the interface org.apache.camel.component.routebox.strategy.RouteboxDispatchStrategy as shown in the example below.
public class SimpleRouteDispatchStrategy implements RouteboxDispatchStrategy {
/* (non-Javadoc)
* @see org.apache.camel.component.routebox.strategy.RouteboxDispatchStrategy#selectDestinationUri(java.util.List, org.apache.camel.Exchange)
*/
public URI selectDestinationUri(List<URI> activeDestinations,
Exchange exchange) {
URI dispatchDestination = null;
String operation = exchange.getIn().getHeader("ROUTE_DISPATCH_KEY", String.class);
for (URI destination : activeDestinations) {
if (destination.toASCIIString().equalsIgnoreCase("seda:" + operation)) {
dispatchDestination = destination;
break;
}
}
return dispatchDestination;
}
}
When creating a route consumer, note that the # entries in the routeboxUri are matched to the created inner registry, routebuilder list and dispatchStrategy/dispatchMap in the CamelContext Registry. Note that all routebuilders and associated routes are launched in the routebox created inner context
private String routeboxUri = "routebox:multipleRoutes?innerRegistry=#registry&routeBuilders=#routes&dispatchMap=#map";
public void testRouteboxRequests() throws Exception {
CamelContext context = createCamelContext();
template = new DefaultProducerTemplate(context);
template.start();
context.addRoutes(new RouteBuilder() {
public void configure() {
from(routeboxUri)
.to("log:Routes operation performed?showAll=true");
}
});
context.start();
// Now use the ProducerTemplate to send the request to the routebox
template.requestBodyAndHeader(routeboxUri, book, "ROUTE_DISPATCH_KEY", "addToCatalog");
}
When sending requests to the routebox, it is not necessary for producers do not need to know the inner route endpoint URI and they can simply invoke the Routebox URI endpoint with a dispatch strategy or dispatchMap as shown below
It is necessary to set a special exchange Header called ROUTE_DISPATCH_KEY (optional for Dispatch Strategy) with a key that matches a key in the dispatch map so that the request can be sent to the correct inner route
from("direct:sendToStrategyBasedRoutebox")
.to("routebox:multipleRoutes?innerRegistry=#registry&routeBuilders=#routes&dispatchStrategy=#strategy")
.to("log:Routes operation performed?showAll=true");
from ("direct:sendToMapBasedRoutebox")
.setHeader("ROUTE_DISPATCH_KEY", constant("addToCatalog"))
.to("routebox:multipleRoutes?innerRegistry=#registry&routeBuilders=#routes&dispatchMap=#map")
.to("log:Routes operation performed?showAll=true");
The rmi: component binds PojoExchanges to the RMI protocol (JRMP).
Since this binding is just using RMI, normal RMI rules still apply regarding what methods
can be invoked. This component supports only PojoExchanges that carry a method invocation from an interface that extends the
Remote
interface. All parameters in the method should be either Serializable or Remote objects.
rmi://rmi-regisitry-host:rmi-registry-port/registry-path[?options]
For example:
rmi://localhost:1099/path/to/service
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
method
|
null
|
As of Apache Camel 1.3, you can set the name of the method to invoke. |
remoteInterfaces
|
null
|
Its now possible to use this option from Camel 2.7: in the XML DSL. It can be a list of interface names separated by comma. |
To call out to an existing RMI service registered in an RMI registry, create a route similar to the following:
from("pojo:foo").to("rmi://localhost:1099/foo");To bind an existing camel processor or service in an RMI registry, define an RMI endpoint as follows:
RmiEndpoint endpoint= (RmiEndpoint) endpoint("rmi://localhost:1099/bar");
endpoint.setRemoteInterfaces(ISay.class);
from(endpoint).to("pojo:bar");Note that when binding an RMI consumer endpoint, you must specify the
Remote interfaces exposed.
In XML DSL you can do as follows from Camel 2.7 onwards:
<camel:route>
<from uri="rmi://localhost:37541/helloServiceBean?remoteInterfaces=org.apache.camel.example.osgi.HelloService"/>
<to uri="bean:helloServiceBean"/>
</camel:route>The rss: component is used for polling RSS feeds. Apache Camel will default poll the feed every 60th seconds.
Note: The component currently only supports polling (consuming) feeds.
rss:rssUri
Where rssUri is the URI to the RSS feed to poll.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Property | Default | Description |
|---|---|---|
splitEntries
|
true
|
If true, Apache Camel splits a feed into its individual entries and
returns each entry, poll by poll. For example, if a feed contains seven entries, Apache Camel
returns the first entry on the first poll, the second entry on the second poll, and so on.
When no more entries are left in the feed, Apache Camel contacts the remote RSS URI to obtain
a new feed. If false, Apache Camel obtains a fresh feed on every poll and
returns all of the feed's entries. |
filter
|
true
|
Use in combination with the splitEntries option in order to filter
returned entries. By default, Apache Camel applies the UpdateDateFilter
filter, which returns only new entries from the feed, ensuring that the consumer endpoint
never receives an entry more than once. The filter orders the entries chronologically,
with the newest returned last. |
throttleEntries
|
true
|
Camel 2.5: Sets whether all entries identified in a single feed poll should be delivered immediately. If true, only one entry is processed per consumer.delay. Only applicable when splitEntries is set to true. |
lastUpdate
|
null
|
Use in combination with the filter option to block entries earlier
than a specific date/time (uses the entry.updated timestamp). The
format is: yyyy-MM-ddTHH:MM:ss. Example:
2007-12-24T17:45:59. |
feedHeader
|
true
|
Specifies whether to add the ROME SyndFeed object as a header. |
sortEntries
|
false
|
If splitEntries is true, this specifies whether
to sort the entries by updated date. |
consumer.delay
|
60000
|
Delay in milliseconds between each poll. |
consumer.initialDelay
|
1000
|
Milliseconds before polling starts. |
consumer.userFixedDelay
|
false
|
Set to true to use fixed delay between pools, otherwise fixed rate
is used. See ScheduledExecutorService in JDK for details. |
Apache Camel initializes the In body on the Exchange with a ROME SyndFeed.
Depending on the value of the splitEntries flag, Apache Camel returns either a
SyndFeed with one SyndEntry or a
java.util.List of SyndEntrys.
| Option | Value | Behavior |
|---|---|---|
splitEntries
|
true
|
A single entry from the current feed is set in the exchange. |
splitEntries
|
false
|
The entire list of entries from the current feed is set in the exchange. |
| Header | Description |
|---|---|
org.apache.camel.component.rss.feed
|
Apache Camel 1.x: The entire SyncFeed object. |
CamelRssFeed
|
Apache Camel 2.0: The entire SyncFeed object. |
The RSS component ships with an RSS dataformat that can be used to convert between String (as XML) and ROME RSS model objects.
marshal = from ROME SyndFeed to XML String
unmarshal = from XML String to ROME SyndFeed
A route using this would look something like this:
from("rss:file:src/test/data/rss20.xml?splitEntries=false&consumer.delay=1000").marshal().rss().to("mock:marshal");
The purpose of this feature is to make it possible to use Apache Camel's lovely built-in expressions for manipulating RSS messages. As shown below, an XPath expression can be used to filter the RSS message:
// only entries with Apache Camel in the title will get through the filter
from("rss:file:src/test/data/rss20.xml?splitEntries=true&consumer.delay=100")
.marshal().rss().filter().xpath("//item/title[contains(.,'Camel')]").to("mock:result");
You can filter out entries quite easily using XPath, as shown in the data format section above. You can also exploit Apache Camel's Bean Integration to implement your own conditions. For instance, a filter equivalent to the XPath example above would be:
// only entries with Camel in the title will get through the filter
from("rss:file:src/test/data/rss20.xml?splitEntries=true&consumer.delay=100").
filter().method("myFilterBean", "titleContainsCamel").to("mock:result");The custom bean for this would be:
public static class FilterBean {
public boolean titleContainsCamel(@Body SyndFeed feed) {
SyndEntry firstEntry = (SyndEntry) feed.getEntries().get(0);
return firstEntry.getTitle().contains("Camel");
}
}The scalate: component allows you to process a message using Scalate template, which supports either SSP or Scaml format templates. This can be ideal when using Templating to generate responses for requests.
Maven users will need to add the following dependency to their pom.xml for
this component:
<dependency>
<groupId>org.fusesource.scalate</groupId>
<artifactId>scalate-camel</artifactId>
<version>1.0</version>
</dependency>scalate:templateName[?options]
Where templateName is the classpath-local URI of the template to invoke; or the complete URL of the remote template (eg: file://folder/myfile.ssp).
You can append query options to the URI in the following format,
?option=value&option=value&...
The scalate component sets a couple headers on the message (you can't set these yourself and from Apache Camel 2.1 scalate component will not set these headers which will cause some side effect on the dynamic template support):
| Header | Description |
|---|---|
CamelScalateResource
|
The resource as an org.springframework.core.io.Resource object.
|
CamelScalateResourceUri
|
The templateName as a String
object. |
Headers set during the Scalate evaluation are returned to the message and added as headers. Then its kinda possible to return values from Scalate to the Message.
For example, to set the header value of fruit in the Scalate template
.tm:
<% in.setHeader('fruit', 'Apple') %>The fruit header is now accessible from the
message.out.headers.
Apache Camel will provide exchange information in the Scalate context (just a
Map). The Exchange is transfered as:
| key | value |
|---|---|
exchange
|
The Exchange itself. |
headers
|
The headers of the In message. |
camelContext
|
The Camel Context intance. |
request
|
The In message. |
in
|
The In message. |
body
|
The In message body. |
out
|
The Out message (only for InOut message exchange pattern). |
response
|
The Out message (only for InOut message exchange pattern). |
The Scalate template resource is, by default, hot reloadable for both file and classpath resources (expanded jar).
Apache Camel provides two headers by which you can define a different resource location for a template or the template content itself. If any of these headers is set then Apache Camel uses this over the endpoint configured resource. This allows you to provide a dynamic template at runtime.
| Header | Type | Description |
|---|---|---|
| CamelScalateResourceUri | String | An URI for the template resource to use instead of the endpoint configured. |
| CamelScalateTemplate | String | The template to use instead of the endpoint configured. |
For example you could use something like
from("activemq:My.Queue").
to("scalate:com/acme/MyResponse.ssp");To use a Scalate template to formulate a response to a message for InOut message exchanges
(where there is a JMSReplyTo header).
If you want to use InOnly and consume the message and send it to another destination, you could use the following route:
from("activemq:My.Queue").
to("scalate:com/acme/MyResponse.scaml").
to("activemq:Another.Queue");It's possible to specify what template the component should use dynamically via a header, so for example:
from("direct:in").
setHeader("CamelScalateResourceUri").constant("path/to/my/template.scaml").
to("scalate:dummy");It's possible to specify a template directly as a header the component should use dynamically via a header, so for example:
from("direct:in").
setHeader("CamelScalateTemplate").constant("<%@ attribute body: Object %>\nHi this is a scalate template that can do templating ${body}").
to("scalate:dummy");In this sample we want to use Scalate templating for an order confirmation email. The email template is laid out in Scalate as:
<%@ attribute in: org.apache.camel.scala.RichMessage %>
Dear ${in("lastName"}, ${in("firstName")}
Thanks for the order of ${in("item")}.
Regards Camel Riders Bookstore
${in.body}
The snmp: component gives you the ability to poll SNMP capable devices or receiving traps.
snmp://hostname[:port][?Options]
The component supports polling OID values from an SNMP enabled device and receiving traps.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
type
|
none | The type of action you want to perform. Actually you can enter here POLL or TRAP. The value POLL will instruct the endpoint to poll a given host for the supplied OID keys. If you put in TRAP you will setup a listener for SNMP Trap Events. |
address
|
none | This is the IP address and the port of the host to poll or where to setup the Trap
Receiver. Example: 127.0.0.1:162
|
protocol
|
udp | Here you can select which protocol to use. By default it will be udp
protocol but you may want to use tcp as well |
retries
|
2
|
Defines how often a retry is made before canceling the request. |
timeout
|
1500
|
Sets the timeout value for the request in millis. |
snmpVersion
|
0 (which means SNMPv1) |
Sets the snmp version for the request. |
snmpCommunity
|
public
|
Sets the community octet string for the snmp request. |
delay
|
60 seconds |
Defines the delay in seconds between to poll cycles. |
oids
|
none | Defines which values you are interested in. Please have a look at the Wikipedia to get a
better understanding. You may provide a single OID or a coma separated list of OIDs.
Example:
oids="1.3.6.1.2.1.1.3.0,1.3.6.1.2.1.25.3.2.1.5.1,1.3.6.1.2.1.25.3.5.1.1.1,1.3.6.1.2.1.43.5.1.1.11.1"
|
Given the situation, that I poll for the following OIDs:
1.3.6.1.2.1.1.3.0 1.3.6.1.2.1.25.3.2.1.5.1 1.3.6.1.2.1.25.3.5.1.1.1 1.3.6.1.2.1.43.5.1.1.11.1
The result will be the following:
<?xml version="1.0" encoding="UTF-8"?>
<snmp>
<entry>
<oid>1.3.6.1.2.1.1.3.0</oid>
<value>6 days, 21:14:28.00</value>
</entry>
<entry>
<oid>1.3.6.1.2.1.25.3.2.1.5.1</oid>
<value>2</value>
</entry>
<entry>
<oid>1.3.6.1.2.1.25.3.5.1.1.1</oid>
<value>3</value>
</entry>
<entry>
<oid>1.3.6.1.2.1.43.5.1.1.11.1</oid>
<value>6</value>
</entry>
<entry>
<oid>1.3.6.1.2.1.1.1.0</oid>
<value>My Very Special Printer Of Brand Unknown</value>
</entry>
</snmp>As you maybe recognized there is one more result than requested....1.3.6.1.2.1.1.1.0. This one is filled in by the device automatically in this special case. So it may absolutely happen, that you receive more than you requested...be prepared.
Polling a remote device:
snmp:192.168.178.23:161?protocol=udp&type=POLL&oids=1.3.6.1.2.1.1.5.0
Setting up a trap receiver (no OID info is needed here!):
snmp:127.0.0.1:162?protocol=udp&type=TRAP
Routing example in Java (converts the SNMP PDU to XML String):
from("snmp:192.168.178.23:161?protocol=udp&type=POLL&oids=1.3.6.1.2.1.1.5.0").
convertBodyTo(String.class).
to("activemq:snmp.states");The spring-integration: component provides a bridge for Apache Camel components to talk to spring integration endpoints.
spring-integration:defaultChannelName[?options]
Where defaultChannelName represents the default channel
name which is used by the Spring Integration Spring context. It will equal to the
inputChannel name for the Spring Integration consumer and the
outputChannel name for the Spring Integration provider.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Description | Example | Required | Default Value |
|---|---|---|---|---|
inputChannel
|
The Spring integration input channel name that this endpoint wants to consume from, where the specified channel name is defined in the Spring context. | inputChannel=requestChannel
|
No | |
outputChannel
|
The Spring integration output channel name that is used to send messages to the Spring integration context. | outputChannel=replyChannel
|
No | |
inOut
|
The exchange pattern that the Spring integration endpoint should use. | inOut=true
|
No | inOnly for the Spring integration consumer and
outOnly for the Spring integration provider |
consumer.delay
|
Delay in milliseconds between each poll. | consumer.delay=60000
|
No | 500
|
consumer.initialDelay
|
Milliseconds before polling starts. | consumer.initialDelay=10000
|
No | 1000
|
consumer.userFixedDelay
|
Specify true to use fixed delay between polls, otherwise fixed rate
is used. See the Java[ScheduledExecutorService|http://java.sun.com/j2se/1.5.0/docs/api/index.html?java/lang/Character.html]
class for details. |
consumer.userFixedDelay=false
|
No | false
|
The Spring integration component is a bridge that connects Apache Camel endpoints with Spring integration endpoints through the Spring integration's input channels and output channels. Using this component, we can send Camel messages to Spring Integration endpoints or receive messages from Spring integration endpoints in a Camel routing context.
You can set up a Spring integration endpoint using a URI, as follows:
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd">
<channel id="inputChannel"/>
<channel id="outputChannel"/>
<channel id="onewayChannel"/>
<service-activator input-channel="inputChannel"
ref="helloService"
method="sayHello"/>
<service-activator input-channel="onewayChannel"
ref="helloService"
method="greet"/>
<beans:bean id="helloService" class="org.apache.camel.component.spring.integration.HelloWorldService"/>
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:twowayMessage"/>
<!-- Using the &as the separator of & -->
<to uri="spring-integration:inputChannel?inOut=true&nputChannel=outputChannel"/>
</route>
<route>
<from uri="direct:onewayMessage"/>
<to uri="spring-integration:onewayChannel?inOut=false"/>
</route>
</camelContext><channel id="requestChannel"/>
<channel id="responseChannel"/>
<beans:bean id="myProcessor" class="org.apache.camel.component.spring.integration.MyProcessor"/>
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<!-- Using the &as the separator of & -->
<from uri="spring-integration://requestChannel?outputChannel=responseChannel&nOut=true"/>
<process ref="myProcessor"/>
</route>
</camelContext>Or directly using a Spring integration channel name:
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:beans="http://www.springframework.org/schema/beans"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd">
<channel id="outputChannel"/>
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<!-- camel will create a spring integration endpoint automatically -->
<from uri="outputChannel"/>
<to uri="mock:result"/>
</route>
</camelContext>Spring integration also provides the Spring integration's source and target adapters, which can route messages from a Spring integration channel to a Apache Camel endpoint or from a Apache Camel endpoint to a Spring integration channel.
This example uses the following namespaces:
<beans:beans xmlns="http://www.springframework.org/schema/integration"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:camel-si="http://camel.apache.org/schema/spring/integration"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/integration
http://www.springframework.org/schema/integration/spring-integration.xsd
http://camel.apache.org/schema/spring/integration
http://camel.apache.org/schema/spring/integration/camel-spring-integration.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
">You can bind your source or target to a Apache Camel endpoint as follows:
<!-- Create the camel context here -->
<camelContext id="camelTargetContext" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:EndpointA" />
<to uri="mock:result" />
</route>
<route>
<from uri="direct:EndpointC"/>
<process ref="myProcessor"/>
</route>
</camelContext>
<!-- We can bind the camelTarget to the camel context's endpoint by specifying the camelEndpointUri attribute -->
<camel-si:camelTarget id="camelTargetA" camelEndpointUri="direct:EndpointA" expectReply="false">
<camel-si:camelContextRef>camelTargetContext</camel-si:camelContextRef>
</camel-si:camelTarget>
<camel-si:camelTarget id="camelTargetB" camelEndpointUri="direct:EndpointC" replyChannel="channelC" expectReply="true">
<camel-si:camelContextRef>camelTargetContext</camel-si:camelContextRef>
</camel-si:camelTarget>
<camel-si:camelTarget id="camelTargetD" camelEndpointUri="direct:EndpointC" expectReply="true">
<camel-si:camelContextRef>camelTargetContext</camel-si:camelContextRef>
</camel-si:camelTarget>
<beans:bean id="myProcessor" class="org.apache.camel.component.spring.integration.MyProcessor"/>
<!-- spring integration channels -->
<channel id="channelA"/>
<channel id="channelB"/>
<channel id="channelC"/>
<!-- spring integration service activator -->
<service-activator input-channel="channelB" output-channel="channelC" ref="helloService" method="sayHello"/>
<!-- custom bean -->
<beans:bean id="helloService" class="org.apache.camel.component.spring.integration.HelloWorldService"/>
<camelContext id="camelSourceContext" xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:OneWay"/>
<to uri="direct:EndpointB" />
</route>
<route>
<from uri="direct:TwoWay"/>
<to uri="direct:EndpointC" />
</route>
</camelContext>
<!-- camelSource will redirect the message coming for direct:EndpointB to the spring requestChannel channelA -->
<camel-si:camelSource id="camelSourceA" camelEndpointUri="direct:EndpointB"
requestChannel="channelA" expectReply="false">
<camel-si:camelContextRef>camelSourceContext</camel-si:camelContextRef>
</camel-si:camelSource>
<!-- camelSource will redirect the message coming for direct:EndpointC to the spring requestChannel channelB
then it will pull the response from channelC and put the response message back to direct:EndpointC -->
<camel-si:camelSource id="camelSourceB" camelEndpointUri="direct:EndpointC"
requestChannel="channelB" replyChannel="channelC" expectReply="true">
<camel-si:camelContextRef>camelSourceContext</camel-si:camelContextRef>
</camel-si:camelSource>Available as of Camel 2.6
The spring-ws: component allows you to integrate with Spring Web Services. It offers both clientside support, for accessing web services, and serverside support for creating your own contract-first web services.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-spring-ws</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
| Dependencies |
|---|---|
This component offers support for Spring-WS 1.5.9 which is compatible with Spring 2.5.x and 3.0.x. In order to run camel-spring-ws on Spring 2.5.x you need to add the spring-webmvc module from Spring 2.5.x. In order to run Spring-WS 1.5.9 on Spring 3.0 you need to exclude the OXM module from Spring 3.0 as this module is also included in Spring-WS 1.5.9 (see this post) |
The URI scheme for this component is as follows
spring-ws:[mapping-type:]address[?options]
To expose a web service mapping-type needs to be set to any of the following:
| Mapping type | Description |
|---|---|
rootqname
|
Offers the option to map web service requests based on the qualified name of the root element contained in the message. |
soapaction
|
Used to map web service requests based on the SOAP action specified in the header of the message. |
uri
|
In order to map web service requests that target a specific URI. |
xpathresult
|
Used to map web service requests based on the evaluation of an XPath expression against the incoming message. The result of the evaluation should match the XPath result specified in the endpoint URI. |
beanname
|
Allows you to reference a org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher in order to integrate with existing (legacy) endpoint mappings like PayloadRootQNameEndpointMapping, SoapActionEndpointMapping, etc |
As a consumer the address should contain a value relevant to the specified mapping-type (e.g. a SOAP action, XPath expression). As a producer the address should be set to the URI of the web service your calling upon.
You can append query options to the URI in the following format, ?option=value&option=value&...
| Name | Required? | Description |
|---|---|---|
soapAction
|
No | SOAP action to include inside a SOAP request when accessing remote web services |
wsAddressingAction
|
No | WS-Addressing 1.0 action header to include when accessing web services. The To header is set to the address of the web service as specified in the endpoint URI (default Spring-WS behavior). |
expression
|
Only when mapping-type is xpathresult
|
XPath expression to use in the process of mapping web service requests, should match the result specified by xpathresult
|
The following options can be specified in the registry (most likely a Spring ApplicationContext) and referenced from the endpoint URI using the # notation.
| Name | Required? | Description |
|---|---|---|
webServiceTemplate
|
No | Option to provide a custom WebServiceTemplate. This allows for full control over client-side web services handling; like adding a custom interceptor or specifying a fault resolver, message sender or message factory. |
messageSender
|
No | Option to provide a custom WebServiceMessageSender. For example to perform authentication or use alternative transports |
messageFactory
|
No | Option to provide a custom WebServiceMessageFactory. For example when you want Apache Axiom to handle web service messages instead of SAAJ |
transformerFactory
|
No | Option to override default TransformerFactory. The provided transformer factory must be of type javax.xml.transform.TransformerFactory
|
endpointMapping
|
Only when mapping-type is rootqname, soapaction, uri or xpathresult
|
Reference to org.apache.camel.component.spring.ws.bean.CamelEndpointMapping in the Registry/ApplicationContext. Only one bean is required in the registry to serve all Camel/Spring-WS endpoints. This bean is auto-discovered by the MessageDispatcher and used to map requests to Camel endpoints based on characteristics specified on the endpoint (like root QName, SOAP action, etc) |
| Name | Type | Description |
|---|---|---|
CamelSpringWebserviceEndpointUri
|
String | URI of the web service your accessing as a client, overrides address part of the endpoint URI |
CamelSpringWebserviceSoapAction
|
String | Header to specify the SOAP action of the message, overrides soapAction option if present |
CamelSpringWebserviceAddressingAction
|
URI | Use this header to specify the WS-Addressing action of the message, overrides wsAddressingAction option if present |
To call a web service at
http://foo.com/bar simply define a route:
from("direct:example").to("spring-ws:http://foo.com/bar")
And sent a message:
template.requestBody("direct:example", "<foobar xmlns=\"http://foo.com\"><msg>test message</msg></foobar>");
When a remote web service requires a SOAP action or use of the WS-Addressing standard you define your route as:
from("direct:example")
.to("spring-ws:http://foo.com/bar?soapAction=http://foo.com&wsAddressingAction=http://bar.com")
Optionally you can override the endpoint options with header values:
template.requestBodyAndHeader("direct:example",
"<foobar xmlns=\"http://foo.com\"><msg>test message</msg></foobar>",
SpringWebserviceConstants.SPRING_WS_SOAP_ACTION, "http://baz.com");
A custom message sender or factory in the registry can be referenced like this:
from("direct:example")
.to("spring-ws:http://foo.com/bar?messageFactory=#messageFactory&messageSender=#messageSender")
Spring configuration:
<!-- authenticate using HTTP Basic Authentication --> <bean id="messageSender" class="org.springframework.ws.transport.http.CommonsHttpMessageSender"> <property name="credentials"> <bean class="org.apache.commons.httpclient.UsernamePasswordCredentials"> <constructor-arg index="0" value="admin"/> <constructor-arg index="1" value="secret"/> </bean> </property> </bean> <!-- force use of Sun SAAJ implementation, http://static.springsource.org/spring-ws/sites/1.5/faq.html#saaj-jboss --> <bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory"> <property name="messageFactory"> <bean class="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"></bean> </property> </bean>
In order to expose a web service using this component you first need to set-up a MessageDispatcher to look for endpoint mappings in a Spring XML file. If you plan on running inside a servlet container you probably want to use a MessageDispatcherServlet configured in web.xml.
By default the MessageDispatcherServlet will look for a Spring XML named /WEB-INF/spring-ws-servlet.xml. To use Camel with Spring-WS the only mandatory bean in that XML file is CamelEndpointMapping. This bean allows the MessageDispatcher to dispatch web service requests to your routes.
web.xml
<web-app>
<servlet>
<servlet-name>spring-ws</servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring-ws</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
spring-ws-servlet.xml
<bean id="endpointMapping" class="org.apache.camel.component.spring.ws.bean.CamelEndpointMapping" /> <bean id="wsdl" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition"> <property name="schema"> <bean class="org.springframework.xml.xsd.SimpleXsdSchema"> <property name="xsd" value="/WEB-INF/foobar.xsd"/> </bean> </property> <property name="portTypeName" value="FooBar"/> <property name="locationUri" value="/"/> <property name="targetNamespace" value="http://example.com/"/> </bean>
More information on setting up Spring-WS can be found in Writing Contract-First Web Services. Basically paragraph 3.6 "Implementing the Endpoint" is handled by this component (specifically paragraph 3.6.2 "Routing the Message to the Endpoint" is where CamelEndpointMapping comes in).
With the XML configuration in-place you can now use Camel's DSL to define what web service requests are handled by your endpoint:
The following route will receive all web service requests that have a root element named "GetFoo" within the
http://example.com/ namespace.
from("spring-ws:rootqname:{http://example.com/}GetFoo?endpointMapping=#endpointMapping")
.convertBodyTo(String.class).to(mock:example)
The following route will receive web service requests containing the
http://example.com/GetFoo SOAP action.
from("spring-ws:soapaction:http://example.com/GetFoo?endpointMapping=#endpointMapping")
.convertBodyTo(String.class).to(mock:example)
The following route will receive all requests sent to
http://example.com/foobar.
from("spring-ws:uri:http://example.com/foobar?endpointMapping=#endpointMapping")
.convertBodyTo(String.class).to(mock:example)
The route below will receive requests that contain the element <foobar>abc</foobar> anywhere inside the message (and the default namespace).
from("spring-ws:xpathresult:abc?expression=//foobar&endpointMapping=#endpointMapping")
.convertBodyTo(String.class).to(mock:example)
For every endpoint with mapping-type beanname one bean of type CamelEndpointDispatcher with a corresponding name is required in the Registry/ApplicationContext. This bean acts as a bridge between the Camel endpoint and an existing endpoint mapping like PayloadRootQNameEndpointMapping.
| Note |
|---|---|
The use of the |
An example of a route using beanname:
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="spring-ws:beanname:QuoteEndpointDispatcher" />
<to uri="mock:example" />
</route>
</camelContext>
<bean id="legacyEndpointMapping" class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
<property name="mappings">
<props>
<prop key="{http://example.com/}GetFuture">FutureEndpointDispatcher</prop>
<prop key="{http://example.com/}GetQuote">QuoteEndpointDispatcher</prop>
</props>
</property>
</bean>
<bean id="QuoteEndpointDispatcher" class="org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher" />
<bean id="FutureEndpointDispatcher" class="org.apache.camel.component.spring.ws.bean.CamelEndpointDispatcher" />
Camel's pluggable data formats offer support for pojo/xml marshalling using libraries such as JAXB, XStream, Castor and XMLBeans. You can use these data formats in your route to sent and receive pojo's, to and from web services.
When accessing web services you can marshal the request and unmarshal the response message:
JaxbDataFormat jaxb = new JaxbDataFormat(false);
jaxb.setContextPath("com.example.model");
from("direct:example").marshal(jaxb).to("spring-ws:http://foo.com/bar").unmarshal(jaxb);
Similarly when providing web services, you can unmarshal XML requests to POJO's and marshal the response message back to XML:
from("spring-ws:rootqname:{http://example.com/}GetFoo?endpointMapping=#endpointMapping").unmarshal(jaxb)
.to("mock:example").marshal(jaxb);
The sql: component allows you to work with databases using JDBC queries. The difference between this component and JDBC component is that in case of SQL the query is a property of the endpoint and it uses message payload as parameters passed to the query.
This component uses spring-jdbc behind the scenes for the actual SQL
handling.
The SQL component also supports:
a JDBC based repository for the Idempotent Consumer EIP pattern. See further below.
a JDBC based repository for the Aggregator EIP pattern. See further below.
| Warning |
|---|---|
The SQL component can only be used to define producer endpoints. In other words, you
cannot define an SQL endpoint in a |
The SQL component uses the following endpoint URI notation:
sql:select * from table where id=# order by name[?options]
Notice that the standard ? symbol that denotes the parameters to an SQL
query is substituted with the # symbol, because the ?
symbol is used to specify options for the endpoint. The ? symbol replacement can be configured on endpoint basis.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Type | Default | Description |
|---|---|---|---|
dataSourceRef
|
String
|
null
|
Apache Camel 1.5.1/2.0: Reference to a
DataSource to look up in the registry. |
placeholder
|
String
|
#
|
Camel 2.4: Specifies a character that will be replaced to ? in SQL query. Notice, that it is simple String.replaceAll() operation and no SQL parsing is involved (quoted strings will also change) |
template.<xxx>
|
null
|
Sets additional options on the Spring JdbcTemplate that is used
behind the scenes to execute the queries. For instance,
template.maxRows=10. For detailed documentation, see the JdbcTemplate javadoc documentation. |
The SQL component tries to convert the message body to an object of
java.util.Iterator type and then uses this iterator to fill the query
parameters (where each query parameter is represented by a # symbol, or other configured placeholder, in the
endpoint URI). If the message body is not an array or collection, the conversion results in an
iterator that iterates over only one object, which is the body itself.
For example, if the message body is an instance of java.util.List, the
first item in the list is substituted into the first occurrence of # in the
SQL query, the second item in the list is substituted into the second occurrence of
#, and so on.
For select operations, the result is an instance of
List<Map<String, Object>> type, as returned by the JdbcTemplate.queryForList() method. For update operations, the
result is the number of updated rows, returned as an Integer.
When performing update operations, the SQL Component stores the update
count in the following message headers:
| Header | Description |
|---|---|
SqlProducer.UPDATE_COUNT
|
Apache Camel 1.x: The number of rows updated for update operations,
returned as an Integer object. |
CamelSqlUpdateCount
|
Apache Camel 2.0: The number of rows updated for update operations,
returned as an Integer object. |
CamelSqlRowCount
|
Apache Camel 2.0: The number of rows returned for select operations,
returned as an Integer object. |
The SQL component must be configured before it can be used. In Spring, you can configure it as follows:
<bean id="sql" class="org.apache.camel.component.sql.SqlComponent">
<property name="dataSource" ref="myDS"/>
</bean>
<bean id="myDS" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="jdbc:mysql://localhost:3306/ds" />
<property name="username" value="username" />
<property name="password" value="password" />
</bean>You can now set a reference to a DataSource in the URI directly:
sql:select * from table where id=# order by name?dataSourceRef=myDS
In the sample below we execute a query and retrieve the result as a
List of rows, where each row is a Map<String,
Object and the key is the column name.
First, we set up a table to use for our sample. As this is based on an unit test, we do it java code:
// this is the database we create with some initial data for our unit test
jdbcTemplate.execute("create table projects (id integer primary key,"
+ "project varchar(10), license varchar(5))");
jdbcTemplate.execute("insert into projects values (1, 'Camel', 'ASF')");
jdbcTemplate.execute("insert into projects values (2, 'AMQ', 'ASF')");
jdbcTemplate.execute("insert into projects values (3, 'Linux', 'XXX')");Then we configure our route and our sql component. Notice that we use a
direct endpoint in front of the sql endpoint. This
allows us to send an exchange to the direct endpoint with the URI,
direct:simple, which is much easier for the client to use than the long
sql: URI. Note that the DataSource is looked up up in
the registry, so we can use standard Spring XML to configure our
DataSource.
from("direct:simple")
.to("sql:select * from projects where license = # order by id?dataSourceRef=jdbc/myDataSource")
.to("mock:result");And then we fire the message into the direct endpoint that will route
it to our sql component that queries the database.
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedMessageCount(1);
// send the query to direct that will route it to the sql where we will execute the query
// and bind the parameters with the data from the body. The body only contains one value
// in this case (XXX) but if we should use multi values then the body will be iterated
// so we could supply a List<String> instead containing each binding value.
template.sendBody("direct:simple", "XXX");
mock.assertIsSatisfied();
// the result is a List
List received = assertIsInstanceOf(List.class, mock.getReceivedExchanges().get(0).getIn().getBody());
// and each row in the list is a Map
Map row = assertIsInstanceOf(Map.class, received.get(0));
// and we should be able the get the project from the map that should be Linux
assertEquals("Linux", row.get("PROJECT"));We could configure the DataSource in Spring XML as follows:
<jee:jndi-lookup id="myDS" jndi-name="jdbc/myDataSource"/>
Available as of Camel 2.7: In this section we will use the JDBC based idempotent repository.
First we need to setup a javax.sql.DataSource in the Spring XML file:
<bean id="dataSource" class="org.springframework.jdbc.datasource.SingleConnectionDataSource">
<property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
<property name="url" value="jdbc:hsqldb:mem:camel_jdbc"/>
<property name="username" value="sa"/>
<property name="password" value=""/>
</bean>And finally we can create our JDBC idempotent repository in the Spring XML file as well:
<bean id="messageIdRepository" class="org.apache.camel.processor.idempotent.jdbc.JdbcMessageIdRepository"> <constructor-arg ref="dataSource" /> <constructor-arg value="myProcessorName" /> </bean> <camel:camelContext> <camel:errorHandler id="deadLetterChannel" type="DeadLetterChannel" deadLetterUri="mock:error"> <camel:redeliveryPolicy maximumRedeliveries="0" maximumRedeliveryDelay="0" logStackTrace="false" /> </camel:errorHandler> <camel:route id="JdbcMessageIdRepositoryTest" errorHandlerRef="deadLetterChannel"> <camel:from uri="direct:start" /> <camel:idempotentConsumer messageIdRepositoryRef="messageIdRepository"> <camel:header>messageId</camel:header> <camel:to uri="mock:result" /> </camel:idempotentConsumer> </camel:route> </camel:camelContext>
Available as of Camel 2.6
| Using JdbcAggregationRepository in Camel 2.6 |
|---|---|
In Camel 2.6, the JdbcAggregationRepository is provided in the |
JdbcAggregationRepository is an AggregationRepository which on the fly persists the aggregated messages. This ensures that you will not loose messages, as the default aggregator will use an in memory only AggregationRepository.
The JdbcAggregationRepository allows together with Camel to provide persistent support for the Aggregator.
It has the following options:
| Option | Type | Description |
|---|---|---|
dataSource
|
DataSource
|
Mandatory: The javax.sql.DataSource to use for accessing the database. |
repositoryName
|
String
|
Mandatory: The name of the repository. |
transactionManager
|
TransactionManager
|
Mandatory: The org.springframework.transaction.PlatformTransactionManager to mange transactions for the database. The TransactionManager must be able to support databases. |
lobHandler
|
LobHandler
|
A org.springframework.jdbc.support.lob.LobHandler to handle Lob types in the database. Use this option to use a vendor specific LobHandler, for example when using Oracle. |
returnOldExchange
|
boolean | Whether the get operation should return the old existing Exchange if any existed. By default this option is false to optimize as we do not need the old exchange when aggregating. |
useRecovery
|
boolean | Whether or not recovery is enabled. This option is by default true. When enabled the Aggregator automatic recover failed aggregated exchange and have them resubmitted. |
recoveryInterval
|
long | If recovery is enabled then a background task is run every x'th time to scan for failed exchanges to recover and resubmit. By default this interval is 5000 millis. |
maximumRedeliveries
|
int | Allows you to limit the maximum number of redelivery attempts for a recovered exchange. If enabled then the Exchange will be moved to the dead letter channel if all redelivery attempts failed. By default this option is disabled. If this option is used then the deadLetterUri option must also be provided. |
deadLetterUri
|
String | An endpoint uri for a Dead Letter Channel where exhausted recovered Exchanges will be moved. If this option is used then the maximumRedeliveries option must also be provided. |
JdbcAggregationRepository will only preserve any Serializable compatible data types. If a data type is not such a type its dropped and a WARN is logged. And it only persists the Message body and the Message headers. The Exchange properties are not persisted.
The JdbcAggregationRepository will by default recover any failed exchange. It does this by having a background tasks that scans for failed Exchanges in the persistent store. You can use the checkInterval option to set how often this task runs. The recovery works as transactional which ensures that Camel will try to recover and redeliver the failed Exchange. Any Exchange which was found to be recovered will be restored from the persistent store and resubmitted and send out again.
The following headers is set when an exchange is being recovered/redelivered:
| Header | Type | Description |
|---|---|---|
Exchange.REDELIVERED
|
Boolean | Is set to true to indicate the Exchange is being redelivered. |
Exchange.REDELIVERY_COUNTER
|
Integer | The redelivery attempt, starting from 1. |
Only when an Exchange has been successfully processed it will be marked as complete which happens when the confirm method is invoked on the AggregationRepository. This means if the same Exchange fails again it will be kept retried until it success.
You can use option maximumRedeliveries to limit the maximum number of redelivery attempts for a given recovered Exchange. You must also set the deadLetterUri option so Camel knows where to send the Exchange when the maximumRedeliveries was hit.
You can see some examples in the unit tests of camel-sql, for example this test.
To be operational, each aggregator uses two table: the aggregation and completed one. By convention the completed has the same name as the aggregation one suffixed with "_COMPLETED". The name must be configured in the Spring bean with the RepositoryName property. In the following example aggregation will be used.
The table structure definition of both table are identical: in both case a String value is used as key (id) whereas a Blob contains the exchange serialized in byte array. However one difference should be remembered: the id field does not have the same content depending on the table. In the aggregation table id holds the correlation Id used by the component to aggregate the messages. In the completed table, id holds the id of the exchange stored in corresponding the blob field.
Here is the SQL query used to create the tables, just replace "aggregation" with your aggregator repository name.
CREATE TABLE aggregation (
id varchar(255) NOT NULL,
exchange blob NOT NULL,
constraint aggregation_pk PRIMARY KEY (id)
);
CREATE TABLE aggregation_completed (
id varchar(255) NOT NULL,
exchange blob NOT NULL,
constraint aggregation_completed_pk PRIMARY KEY (id)
);Since they can contain any type of payload, Exchanges are not serializable by design. It is converted into a byte array to be stored in a database BLOB field. All those conversions are handled by the JdbcCodec class. One detail of the code requires your attention: the ClassLoadingAwareObjectInputStream.
The ClassLoadingAwareObjectInputStream has been reused from the Apache ActiveMQ project. It wraps an ObjectInputStream and use it with the ContextClassLoader rather than the currentThread one. The benefit is to be able to load classes exposed by other bundles. This allows the exchange body and headers to have custom types object references.
The start method verify the connection of the database and the presence of the required tables. If anything is wrong it will fail during starting.
Depending on the targeted environment, the aggregator might need some configuration. As you already know, each aggregator should have its own repository (with the corresponding pair of table created in the database) and a data source. If the default lobHandler is not adapted to your database system, it can be injected with the lobHandler property.
Here is the declaration for Oracle:
<bean id="lobHandler" class="org.springframework.jdbc.support.lob.OracleLobHandler">
<property name="nativeJdbcExtractor" ref="nativeJdbcExtractor"/>
</bean>
<bean id="nativeJdbcExtractor" class="org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtractor"/>
<bean id="repo" class="org.apache.camel.processor.aggregate.jdbc.JdbcAggregationRepository">
<property name="transactionManager" ref="transactionManager"/>
<property name="repositoryName" value="aggregation"/>
<property name="dataSource" ref="dataSource"/>
<!-- Only with Oracle, else use default -->
<property name="lobHandler" ref="lobHandler"/>
</bean>See also:
The stream: component provides access to the
System.in, System.out and
System.err streams as well as allowing streaming of file and
URL.
stream:in[?options] stream:out[?options] stream:err[?options] stream:header[?options]
In addition, the file and url
endpoint URIs are supported in Apache Camel 2.0:
stream:file?fileName=/foo/bar.txt stream:url[?options]
If the stream:header URI is specified, the
stream header is used to find the stream to write to. This option
is available only for stream producers (that is, it cannot appear in
from()).
You can append query options to the URI in the following format,
?option=value&option=value&...
| Name | Default Value | Description |
|---|---|---|
delay
|
0
|
Initial delay in milliseconds before consuming or producing the stream. |
encoding
|
JVM Default | As of 1.4, you can configure the encoding (is a charset name) to use text-based streams (for example, message body
is a String object). If not provided, Apache Camel uses the JVM default Charset. |
promptMessage
|
null
|
Apache Camel 2.0: Message prompt to use when
reading from stream:in; for example, you could set this to
Enter a command:
|
promptDelay
|
0
|
Apache Camel 2.0: Optional delay in milliseconds before showing the message prompt. |
initialPromptDelay
|
2000
|
Apache Camel 2.0: Initial delay in milliseconds before showing the message prompt. This delay occurs only once. Can be used during system startup to avoid message prompts being written while other logging is done to the system out. |
fileName
|
null
|
Apache Camel 2.0: When using the
stream:file URI format, this option specifies the
filename to stream to/from. |
scanStream
|
false
|
Apache Camel 2.0: To be used
for continuously reading a stream such as the unix |
retry
|
false
|
Camel 2.7: will retry opening the file if it's overwritten, somewhat like tail --retry
|
scanStreamDelay
|
0
|
Apache Camel 2.0: Delay in milliseconds between
read attempts when using scanStream. |
groupLines
|
0
|
Camel 2.5: To group X number of lines in the consumer. For example to group 10 lines and therefore only spit out an Exchange with 10 lines, instead of 1 Exchange per line. |
The stream: component supports either
String or byte[] for writing to streams. Just
add either String or byte[] content to the
message.in.body. The special stream:header URI
is used for custom output streams. Just add a java.io.OutputStream
object to message.in.header in the key header. See
samples for an example.
In the following sample we route messages from the direct:in
endpoint to the System.out stream:
@Test
public void testStringContent() throws Exception {
template.sendBody("direct:in", "Hello Text World\n");
}
@Test
public void testBinaryContent() {
template.sendBody("direct:in", "Hello Bytes World\n".getBytes());
}
protected RouteBuilder createRouteBuilder() {
return new RouteBuilder() {
public void configure() {
from("direct:in").to("stream:out");
}
};
}The following sample demonstrates how the header type can be used to determine which
stream to use. In the sample we use our own output stream,
MyOutputStream.
private OutputStream mystream = new MyOutputStream();
private StringBuffer sb = new StringBuffer();
@Test
public void testStringContent() {
template.sendBody("direct:in", "Hello");
// StreamProducer appends \n in text mode
assertEquals("Hello\n", sb.toString());
}
@Test
public void testBinaryContent() {
template.sendBody("direct:in", "Hello".getBytes());
// StreamProducer is in binary mode so no \n is appended
assertEquals("Hello", sb.toString());
}
protected RouteBuilder createRouteBuilder() {
return new RouteBuilder() {
public void configure() {
from("direct:in").setHeader("stream", constant(mystream)).
to("stream:header");
}
};
}
private class MyOutputStream extends OutputStream {
public void write(int b) throws IOException {
sb.append((char)b);
}
}The following sample demonstrates how to continuously read a file stream (analogous to
the UNIX tail command):
from("stream:file?fileName=/server/logs/server.log&scanStream=true&scanStreamDelay=1000").to("bean:logService?method=parseLogLine"); | Note |
|---|---|
One difficulty with using the combination of |
The string-template: component allows you to process a message using a String Template. This can be ideal when using Templating to generate responses for requests.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-stringtemplate</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
string-template:templateName[?options]
Where templateName is the classpath-local URI of the template to invoke; or the complete URL of the remote template.
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default | Description |
|---|---|---|
contentCache
|
false
|
New option in Apache Camel 1.4. Cache for the resource content when its loaded. |
Apache Camel will store a reference to the resource in the message header with key,
org.apache.camel.stringtemplate.resource. The Resource is an
org.springframework.core.io.Resource object.
The string template resource is by default hot-reloadable for both file and classpath
resources (expanded jar). If you set contentCache=true, Apache Camel
loads the resource only once and hot-reloading is not possible. This scenario can be
used in production when the resource never changes.
Apache Camel will provide exchange information as attributes (just a
java.util.Map) to the string template. The Exchange is transfered
as:
| key | value |
|---|---|
exchange
|
The Exchange itself. |
headers
|
The headers of the In message. |
camelContext
|
The Camel Context. |
request
|
The In message. |
in
|
The In message. |
body
|
The In message body. |
out
|
The Out message (only for InOut message exchange pattern). |
response
|
The Out message (only for InOut message exchange pattern). |
For example you could use a string template as follows in order to formulate a response to a message:
from("activemq:My.Queue").
to("string-template:com/acme/MyResponse.tm");In this sample we want to use a string template to send an order confirmation email.
The email template is laid out in StringTemplate as:
Dear $headers.lastName$, $headers.firstName$ Thanks for the order of $headers.item$. Regards Camel Riders Bookstore $body$
And the java code is as follows:
private Exchange createLetter() {
Exchange exchange = context.getEndpoint("direct:a").createExchange();
Message msg = exchange.getIn();
msg.setHeader("firstName", "Claus");
msg.setHeader("lastName", "Ibsen");
msg.setHeader("item", "Camel in Action");
msg.setBody("PS: Next beer is on me, James");
return exchange;
}
@Test
public void testVelocityLetter() throws Exception {
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedMessageCount(1);
mock.expectedBodiesReceived("Dear Ibsen, Claus! Thanks for the order of Camel in Action. Regards Camel Riders Bookstore PS: Next beer is on me, James");
template.send("direct:a", createLetter());
mock.assertIsSatisfied();
}
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
public void configure() throws Exception {
from("direct:a").to("string-template:org/apache/camel/component/stringtemplate/letter.tm").to("mock:result");
}
};
}The Validation component performs XML validation of the message body using the JAXP Validation API and based on any of the supported XML schema languages, which defaults to XML Schema
Note that the Jing component also supports the following useful schema languages:
The MSV component also supports RelaxNG XML Syntax.
validator:someLocalOrRemoteResource
Where someLocalOrRemoteResource is some URL to a local resource on the classpath or a full URL to a remote resource or resource on the file system which contains the XSD to validate against. For example:
msv:org/foo/bar.xsd
msv:file:../foo/bar.xsd
validator:com/mypackage/myschema.xsd
| Option | Default | Description |
|---|---|---|
useDom
|
false
|
Apache Camel 2.0: Whether
DOMSource/{{DOMResult}} or
SaxSource/{{SaxResult}} should be used by the validator.
|
useSharedSchema
|
true
|
Camel 2.3: Whether the Schema instance should be shared or not. This option is introduced to work around a JDK 1.6.x bug. Xerces should not have this issue. |
The following example shows how to configure a route from endpoint direct:start which then goes to one of two endpoints, either mock:valid or mock:invalid based on whether or not the XML matches the given schema (which is supplied on the classpath).
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<doTry>
<to uri="validator:org/apache/camel/component/validator/schema.xsd"/>
<to uri="mock:valid"/>
<doCatch>
<exception>org.apache.camel.ValidationException</exception>
<to uri="mock:invalid"/>
</doCatch>
<doFinally>
<to uri="mock:finally"/>
</doFinally>
</doTry>
</route>
</camelContext>The velocity: component allows you to process a message using an Apache Velocity template. This can be ideal when using Templating to generate responses for requests.
velocity:templateName[?options]
Where templateName is the classpath-local URI of the
template to invoke; or the complete URL of the remote template (for example,
file://folder/myfile.vm).
You can append query options to the URI in the following format,
?option=value&option=value&...
| Option | Default | Description |
|---|---|---|
loaderCache
|
true
|
Velocity based file loader cache. |
contentCache
|
New option in Apache Camel 1.4: Cache for the resource content when it is loaded.
By default, it's false in Apache Camel 1.x. By default, it's
true in Apache Camel 2.x. |
|
encoding
|
null
|
New option in Apache Camel 1.6: Character encoding of the resource content. |
propertiesFile
|
null
|
New option in Camel 2.1: The URI of the properties file which is used for VelocityEngine initialization. |
The velocity component sets some headers on the message (you cannot set these yourself):
| Header | Description |
|---|---|
org.apache.camel.velocity.resource
|
Apache Camel 1.x: The resource as an
org.springframework.core.io.Resource object. |
org.apache.camel.velocity.resourceUri
|
Apache Camel 1.x: The templateName as a
String object. |
CamelVelocityResource
|
Apache Camel 2.0: The resource as an
org.springframework.core.io.Resource object. |
CamelVelocityResourceUri
|
Apache Camel 2.0: The templateName as a
String object. |
In Apache Camel 1.4 headers set during the Velocity evaluation are returned to the message and added as headers. This makes it possible to return values from Velocity to the Message.
For example, to set the header value of fruit in
the Velocity template .tm:
$in.setHeader('fruit', 'Apple')The fruit header is now accessible from the
message.out.headers.
Apache Camel will provide exchange information in the Velocity context (just a
Map). The Exchange is transfered as:
| key | value |
|---|---|
exchange
|
The Exchange itself. |
headers
|
The headers of the In message. |
camelContext
|
The Camel Context intance. |
request
|
The In message. |
in
|
The In message. |
body
|
The In message body. |
out
|
The Out message (only for InOut message exchange pattern). |
response
|
The Out message (only for InOut message exchange pattern). |
The Velocity template resource is, by default, hot reloadable for both file and
classpath resources (expanded jar). If you set contentCache=true,
Apache Camel will only load the resource once, and thus hot reloading is not possible. This
scenario can be used in production, when the resource never changes.
Available as of Camel 2.1 Camel provides two headers by which you can define a different resource location for a template or the template content itself. If any of these headers is set then Camel uses this over the endpoint configured resource. This allows you to provide a dynamic template at runtime.
| Header | Type | Description |
|---|---|---|
| CamelVelocityResourceUri | String | Camel 2.1: A URI for the template resource to use instead of the endpoint configured. |
| CamelVelocityTemplate | String | Camel 2.1: The template to use instead of the endpoint configured. |
For example you could use something like
from("activemq:My.Queue").
to("velocity:com/acme/MyResponse.vm");To use a Velocity template to formulate a response to a message for InOut message
exchanges (where there is a JMSReplyTo header).
If you want to use InOnly and consume the message and send it to another destination, you could use the following route:
from("activemq:My.Queue").
to("velocity:com/acme/MyResponse.vm").
to("activemq:Another.Queue");And to use the content cache, e.g. for use in production, where the
.vm template never changes:
from("activemq:My.Queue").
to("velocity:com/acme/MyResponse.vm?contentCache=true").
to("activemq:Another.Queue");And a file based resource:
from("activemq:My.Queue").
to("velocity:file://myfolder/MyResponse.vm?contentCache=true").
to("activemq:Another.Queue");
In Camel 2.1 it's possible to specify what template the component should use dynamically via a header, so for example:
from("direct:in").
setHeader("CamelVelocityResourceUri").constant("path/to/my/template.vm").
to("velocity:dummy");
In Camel 2.1 it's possible to specify a template directly as a header the component should use dynamically via a header, so for example:
from("direct:in").
setHeader("CamelVelocityTemplate").constant("Hi this is a velocity template that can do templating ${body}").
to("velocity:dummy");
In this sample we want to use Velocity templating for an order confirmation email. The email template is laid out in Velocity as:
Dear ${headers.lastName}, ${headers.firstName}
Thanks for the order of ${headers.item}.
Regards Camel Riders Bookstore
${body}And the java code:
private Exchange createLetter() {
Exchange exchange = context.getEndpoint("direct:a").createExchange();
Message msg = exchange.getIn();
msg.setHeader("firstName", "Claus");
msg.setHeader("lastName", "Ibsen");
msg.setHeader("item", "Camel in Action");
msg.setBody("PS: Next beer is on me, James");
return exchange;
}
@Test
public void testVelocityLetter() throws Exception {
MockEndpoint mock = getMockEndpoint("mock:result");
mock.expectedMessageCount(1);
mock.expectedBodiesReceived("Dear Ibsen, Claus\n\nThanks for the order of Camel in Action.\n\nRegards Camel Riders Bookstore\nPS: Next beer is on me, James");
template.send("direct:a", createLetter());
mock.assertIsSatisfied();
}
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
public void configure() throws Exception {
from("direct:a").to("velocity:org/apache/camel/component/velocity/letter.vm").to("mock:result");
}
};
}The xquery: component allows you to process a message using an XQuery template. This can be ideal when using Templating to generate respopnses for requests.
xquery:templateName
Where templateName is the classpath-local URI of the template to invoke; or the complete URL of the remote template.
For example you could use something like this:
from("activemq:My.Queue").
to("xquery:com/acme/mytransform.xquery");To use an XQuery template to formulate a response to a message for InOut message exchanges
(where there is a JMSReplyTo header).
If you want to use InOnly, consume the message, and send it to another destination, you could use the following route:
from("activemq:My.Queue").
to("xquery:com/acme/mytransform.xquery").
to("activemq:Another.Queue");The xslt: component allows you to process a message using an XSLT template. This can be ideal when using Templating to generate respopnses for requests.
xslt:templateName[?options]
Where templateName is the classpath-local URI of the template to invoke; or the complete URL of the remote template. Refer to the Spring Documentation for more detail of the URI syntax
You can append query options to the URI in the following format,
?option=value&option=value&...
Here are some example URIs
| URI | Description |
|---|---|
xslt:com/acme/mytransform.xs
|
Refers to the file, com/acme/mytransform.xsl, on the classpath. |
xslt:file:///foo/bar.xs
|
Refers to the file, /foo/bar.xsl. |
xslt:http://acme.com/cheese/foo.xsl
|
Refers to the remote HTTP resource. |
| Name | Default Value | Description |
|---|---|---|
converter
|
null
|
Option to override default XmlConverter. Will lookup for the converter in the Registry. The provided converted must be of type org.apache.camel.converter.jaxp.XmlConverter. |
transformerFactory
|
null
|
New added in Apache Camel 1.6 Option to override default
TransformerFactory. Will lookup for the transformerFactory in the Registry. The
provided transformer factory must be of type
javax.xml.transform.TransformerFactory. |
transformerFactoryClass
|
null
|
New added in Apache Camel 1.6 Option to override default
TransformerFactory. Will create a TransformerFactoryClass instance
and set it to the converter. |
uriResolver
|
null
|
Camel 2.3: Allows you to use a custom
javax.xml.transformation.URIResolver. Camel will by default use its
own implementation org.apache.camel.builder.xml.XsltUriResolver which
is capable of loading from classpath. |
resultHandlerFactory
|
null
|
Camel 2.3: Allows you to use a custom
org.apache.camel.builder.xml.ResultHandlerFactory which is capable of
using custom org.apache.camel.builder.xml.ResultHandler types. |
failOnNullBody
|
true
|
Camel 2.3: Whether or not to throw an exception if the input body is null. |
output
|
string
|
Camel 2.3: Option to specify which output type to use.
Possible values are: string, bytes, DOM, file. The first three options
are all in memory based, where as file is streamed directly to a
java.io.File. For file you must specify the filename in the IN header with the key
Exchange.XSLT_FILE_NAME which is also
CamelXsltFileName. Also any paths leading to the filename must be
created beforehand, otherwise an exception is thrown at runtime. |
contentCache
|
true
|
Camel 2.6: Cache for the resource content (the
stylesheet file) when it is loaded. If set to false Camel will reloader
the stylesheet file on each message processing. This is good for development. |
For example you could use something like
from("activemq:My.Queue").
to("xslt:com/acme/mytransform.xsl");To use an XSLT template to forumulate a response for a message for InOut message exchanges
(where there is a JMSReplyTo header).
If you want to use InOnly and consume the message and send it to another destination you could use the following route:
from("activemq:My.Queue").
to("xslt:com/acme/mytransform.xsl").
to("activemq:Another.Queue");By default, all headers are added as parameters which are available in the XSLT. To do this you will need to declare the parameter so it is then useable.
<setHeader headerName="myParam"><constant>42</constant></setHeader> <to uri="xslt:MyTransform.xsl"/>
And the XSLT just needs to declare it at the top level for it to be available:
<xsl: ...... >
<xsl:param name="myParam"/>
<xsl:template ...>To use the above examples in XML you would use something like
<camelContext xmlns="http://activemq.apache.org/camel/schema/spring">
<route>
<from uri="activemq:My.Queue"/>
<to uri="xslt:org/apache/camel/spring/processor/example.xsl"/>
<to uri="activemq:Another.Queue"/>
</route>
</camelContext>There is a test case along with its Spring XML if you want a concrete example.
Camel 1.6.2/2.2 or older If you use xsl:include in your
XSL files then in Camel 2.2 or older it uses the default
javax.xml.transform.URIResolver which means it can only lookup files from
file system, and its does that relative from the JVM starting folder.
For example this include:
<xsl:include href="staff_template.xsl"/>
Will lookup the staff_tempkalte.xsl file from the starting folder where
the application was started.
Camel 1.6.3/2.3 or newer Now Camel provides its own
implementation of URIResolver which allows Camel to load included files
from the classpath and more intelligent than before.
For example this include:
<xsl:include href="staff_template.xsl"/>
Will now be located relative from the starting endpoint, which for example could be:
.to("xslt:org/apache/camel/component/xslt/staff_include_relative.xsl")Which means Camel will locate the file in the classpath
as org/apache/camel/component/xslt/staff_template.xsl. This allows you to
use xsl include and have xsl files located in the same folder such as we do in the example
org/apache/camel/component/xslt.
You can use the following two prefixes classpath: or
file: to instruct Camel to look either in classpath or file system. If
you omit the prefix then Camel uses the prefix from the endpoint configuration. If that
neither has one, then classpath is assumed.
You can also refer back in the paths such as
<xsl:include href="../staff_other_template.xsl"/>
Which then will resolve the xsl file under
org/apache/camel/component.
