Red Hat Training

A Red Hat training course is available for Red Hat Fuse

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.