Chapter 178. Undertow
Undertow Component
Available as of Camel 2.16
The undertow component provides HTTP-based endpoints for consuming and producing HTTP requests. That is, the Undertow component behaves as a simple Web server. Undertow can also be used as an HTTP client, which mean you can also use it with Camel as a producer.
Maven users will need to add the following dependency to their
pom.xml
for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-undertow</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
URI format
undertow:http://hostname[:port][/resourceUri][?options]
You can append query options to the URI in the following format,
?option=value&option=value&...
Options
Name
|
Default Value
|
Description
|
---|---|---|
httpMethodRestrict
|
Used to only allow consuming if the HttpMethod matches, such as GET/POST/PUT etc. Multiple methods can be specified separated by comma. | |
matchOnUriPrefix
|
Whether or not the consumer should try to find a target consumer by matching the URI prefix if no exact match is found. | |
headerFilterStrategy
|
To use a custom HeaderFilterStrategy to filter header to and from Camel message. | |
sslContextParameters
|
To configure security by using an SSLContextParameters object. See chapter "Configuring Transport Security for Camel Components" in "Security Guide".
|
|
throwExceptionOnFailure | If the option is true, HttpProducer will ignore the Exchange.HTTP_URI header, and use the endpoint's URI for request. You may also set the option throwExceptionOnFailure to be false to let the producer send all the fault response back. | |
transferException | Option 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. | |
undertowHttpBinding | To use a custom UndertowHttpBinding to control the mapping between Camel message and undertow. | |
keepAlive
|
true | Camel 2.16.1: Producer only: Setting to ensure socket is not closed due to inactivity |
tcpNoDelay | true | Camel 2.16.1: Producer only:Setting to improve TCP protocol performance |
reuseAddresses | true | Camel 2.16.1: Producer only:Setting to facilitate socket multiplexing |
options.XXX |
Camel 2.16.1: Producer only:Sets additional channel options. The options that can be used are defined in org.xnio.Options . To configure from endpoint uri, then prefix each option with "option.", such as "option.close-abort=true&option.send-buffer=8192"
|
|
enableOptions | false | Camel 2.17: Specifies whether to enable HTTP OPTIONS for this Undertow consumer. By default OPTIONS is turned off. |
Message Headers
Camel uses the same message headers as the HTTP component. From Camel 2.2, it also uses
Exchange.HTTP_CHUNKED,CamelHttpChunked
header to turn on or turn off the chuched encoding on the camel-undertow consumer.
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.
Component Options
The
UndertowComponent
provides the following options:
Name
|
Default Value
|
Description
|
---|---|---|
undertowHttpBinding
|
|
To use a custom UndertowHttpBinding to control the mapping between Camel message and undertow.
|
httpConfiguration
|
To use the shared HttpConfiguration as base configuration. |
Producer Example
The following is a basic example of how to send an HTTP request to an existing HTTP endpoint.
in Java DSL
from("direct:start").to("undertow:http://www.google.com");
or in Spring XML
<route> <from uri="direct:start"/> <to uri="undertow:http://www.google.com"/> <route>
Consumer Example
In this sample we define a route that exposes a HTTP service at
http://localhost:8080/myapp/myservice
:
<route> <from uri="undertow:http://localhost:8080/myapp/myservice"/> <to uri="bean:myBean"/> </route>
When you specify
localhost
in a URL, Camel exposes the endpoint only on the local TCP/IP network interface, so it cannot be accessed from outside the machine it operates on.
If you need to expose a Jetty endpoint on a specific network interface, the numerical IP address of this interface should be used as the host. If you need to expose a Jetty endpoint on all network interfaces, the
0.0.0.0
address should be used.