Jetty Component

The producer is deprecated - do not use. We only recommend using jetty as consumer (eg from jetty)

The jetty component provides HTTP-based endpoints for consuming and producing HTTP requests. That is, the Jetty component behaves as a simple Web server. Jetty can also be used as an HTTP client which mean you can also use it with Camel as a producer.

Stream

The assert call appears in this example, because the code is part of an unit test. 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 Exchange.HTTP_RESPONSE_CODE data multiple times, e.g., doing multi-casting, or re-delivery error handling, you should use Stream caching or convert the message body to a String which is safe to be re-read multiple times.

Maven users should add the following dependency to their pom.xml to use this component:

xml<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jetty</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>

URI Format

jetty:http://hostname[:port][/resourceUri][?options]

Query options should be appended to the URI using the following format: ?option=value&option=value&...

Options

confluenceTableSmall

Option

Default Value

Description

bridgeEndpoint

false

Camel 2.1: 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 throwExceptionOnFailure to be false to let the HttpProducer send all the fault response back.

Camel 2.3: If the option is true, HttpProducer and CamelServlet will skip the gzip processing if the Content-Encoding is gzip.

Consider setting disableStreamCache=true to optimize when bridging.

chunked

true

Camel 2.2: If this option is false Jetty Servlet will disable the HTTP streaming and set the Content-Length header on the response

continuationTimeout

null

Camel 2.6: Allows to set a timeout in milliseconds when using Jetty as consumer (server). By default Jetty uses 30000. You can use a value of <= 0 to never expire. If a timeout occurs then the request will be expired and Jetty will return back an HTTP error 503 to the client.

Camel 2.19: Producer only Configure a cookie handler to maintain a HTTP session.

disableStreamCache

false

Camel 2.3: Determines whether or not the raw input stream from Jetty is cached or not (Camel will read the stream into a in memory/overflow to file, Stream caching) cache. By default Camel will cache the Jetty input stream to support reading it multiple times to ensure it Camel can retrieve all data from the stream. However, you can set this option to true when you for example need to access the raw stream, such as streaming it directly to a file or other persistent store.

DefaultHttpBinding will copy the request input stream into a stream cache and put it into message body if this option is false to support reading the stream multiple times. If you use Jetty to bridge/proxy an endpoint then consider enabling this option to improve performance, in case you do not need to read the message payload multiple times.

enableCORS

false

Camel 2.15: if the option is true, Jetty server will setup the CrossOriginFilter which supports the CORS out of box.

enableJmx

false

Camel 2.3: If this option is true, Jetty JMX support will be enabled for this endpoint. See Jetty JMX support for more details.

Set this option to false when bridging endpoints, to ensure multi-part requests is proxied/bridged as well.

filterInit.xxx

null

Camel 2.17: Configuration for the InitParameters of filter.

For example, setting filterInit.parameter=valuethe parameter could be used when calling the filter init() method.

filtersRef

null

Camel 2.9: Allows using a custom filters which is putted into a list and can be find in the Registry

handlers

null

Specifies a comma-delimited set of org.mortbay.jetty.Handler instances in your Registry (such as your Spring ApplicationContext). These handlers are added to the Jetty Servlet context (for example, to add security).

Note: you can not use different handlers with different Jetty endpoints using the same port number. The handlers is associated to the port number. If you need different handlers, then use different port numbers.

headerFilterStrategy

null

Camel 2.11: Reference to a instance of org.apache.camel.spi.HeaderFilterStrategy in the Registry. It will be used to apply the custom headerFilterStrategy on the new create HttpJettyEndpoint.

httpBindingRef

null

Reference to an org.apache.camel.component.http.HttpBinding in the Registry. HttpBinding can be used to customize how a response should be written for the consumer.

httpClient.xxx

null

Configuration of Jetty's HttpClient. For example, setting httpClient.idleTimeout=30000 sets the idle timeout to 30 seconds. And httpClient.timeout=30000 sets the request timeout to 30 seconds, in case you want to timeout sooner if you have long running request/response calls.

httpClient

null

To use a shared org.eclipse.jetty.client.HttpClient for all producers created by this endpoint. This option should only be used in special circumstances.

httpClientMinThreads

null

Camel 2.11:Producer only: To set a value for minimum number of threads in HttpClient thread pool. This setting override any setting configured on component level. Notice that both a min and max size must be configured. If not set it default to min 8 threads used in Jetty's thread pool.

httpClientMaxThreads

null

Camel 2.11:Producer only: To set a value for maximum number of threads in HttpClient thread pool. This setting override any setting configured on component level. Notice that both a min and max size must be configured. If not set it default to max 16 threads used in Jetty's thread pool.

httpMethodRestrict

null

Camel 2.11:Consumer only: Used to only allow consuming if the HttpMethod matches, such as GET/POST/PUT etc. From Camel 2.15: multiple methods can be specified separated by comma.

jettyHttpBindingRef

null

Camel 2.6.0+: Reference to an org.apache.camel.component.jetty.JettyHttpBinding in the Registry. JettyHttpBinding can be used to customize how a response should be written for the producer.

matchOnUriPrefix

false

Whether or not the CamelServlet should try to find a target consumer by matching the URI prefix if no exact match is found.

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.

traceEnabled

false

Specifies whether to enable HTTP TRACE for this Jetty consumer. By default TRACE is turned off.

transferException

false

Camel 2.6: If enabled and an Exchange failed processing on the consumer side, and if the caused Exception was send back serialized in the response as a application/x-java-serialized-object content type.

On the producer side the exception will be deserialized and thrown as is, instead of the HttpOperationFailedException. The caused exception is required to be serialized.

urlRewrite

null

Camel 2.11:Producer only Refers to a custom org.apache.camel.component.http.UrlRewrite which allows you to rewrite URLs when you bridge/proxy endpoints.

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 toggle chunked encoding on the camel-jetty consumer. Camel also populates allrequest.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.

From Camel 2.2.0: you can get the request.parameter from the message header not only from GET HTTP Method, but also other HTTP method.

Usage

The Jetty component supports both consumer and producer endpoints. Another option for producing to other HTTP endpoints, is to use the HTTP Component

Consumer Example

In this sample we define a route that exposes a HTTP service at http://localhost:8080/myapp/myservice:{snippet:id=e1|lang=java|url=camel/trunk/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/JettyRouteTest.java}

Usage of localhost

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.

If you actually want to expose routes by HTTP and already have a Servlet, you should instead refer to the Servlet Transport.

Our business logic is implemented in the MyBookService class, which accesses the HTTP request contents and then returns a response.Note: The assert call appears in this example, because the code is part of an unit test.{snippet:id=e2|lang=java|url=camel/trunk/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/JettyRouteTest.java}The following sample shows a content-based route that routes all requests containing the URI parameter, one, to the endpoint, mock:one, and all others to mock:other.{snippet:id=e1|lang=java|url=camel/trunk/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/JettyContentBasedRouteTest.java}If a client sends an HTTP request, http://serverUri?one=hello, the Jetty component will copy the HTTP request parameter, one to the exchange's in.header. We can then use the simple language to route exchanges that contain this header to a specific endpoint and all others to another. If we used a language more powerful than Simple, e.g., EL or OGNL, then we can also test for the parameter value and route based on the header value as well.

Session Support

The session support option, sessionSupport, can be used to enable a HttpSession object and access the session object while processing the exchange.

SSL Support (HTTPS)

Using the JSSE Configuration Utility

From Camel 2.8: the camel-jetty component supports SSL/TLS configuration through the Camel JSSE Configuration Utility. This utility greatly decreases the amount of component specific code you need to write and is configurable at the endpoint and component levels. The following examples demonstrate how to use the utility with the Jetty component.

Configuring Jetty Directly

Jetty provides SSL support out of the box. To enable Jetty to run in SSL mode, simply format the URI using the https:// prefix.

Example:

xml<from uri="jetty:https://0.0.0.0/myapp/myservice/"/>

Jetty also needs to know where to load your keystore from and what passwords to use in order to load the correct SSL certificate. Set the following JVM System Properties:

Before Camel 2.3:

confluenceTableSmall

Property

Description

jetty.ssl.keystore

Specifies the location of the Java keystore file, which contains the Jetty server's own X.509 certificate in a key entry. A key entry stores the X.509 certificate (effectively, the public key) and also its associated private key.

jetty.ssl.password

The store password, which is required to access the keystore file (this is the same password that is supplied to the keystore command's -storepass option).

jetty.ssl.keypassword

The key password, which is used to access the certificate's key entry in the keystore (this is the same password that is supplied to the keystore command's -keypass option).

From Camel 2.3:

confluenceTableSmall

Property

Description

org.eclipse.jetty.ssl.keystore

Specifies the location of the Java keystore file, which contains the Jetty server's own X.509 certificate in a key entry. A key entry stores the X.509 certificate (effectively, the public key) and also its associated private key.

org.eclipse.jetty.ssl.password

The store password, which is required to access the keystore file (this is the same password that is supplied to the keystore command's keystore option).

org.eclipse.jetty.ssl.keypassword

The key password, which is used to access the certificate's key entry in the keystore (this is the same password that is supplied to the keystore command's keystore option).

For details of how to configure SSL on a Jetty endpoint, read the following Jetty documentation. Some SSL properties aren't exposed directly by Camel. However, Camel does expose the underlying SslSocketConnector, which will allow you to set properties like needClientAuth for mutual authentication requiring a client certificate or wantClientAuth for mutual authentication where a client doesn't need a certificate but can have one.

The value you use as keys in the above map is the port you configure Jetty to listen on.

Configuring General SSL Properties

From Camel 2.5: instead of a per port number specific SSL socket connector (as shown above) you can now configure general properties which applies for all SSL socket connectors (which is not explicit configured as above with the port number as entry).

Configuring General HTTP Properties

From Camel 2.5: instead of a per port number specific HTTP socket connector (as shown above) you can now configure general properties which applies for all HTTP socket connectors (which is not explicit configured as above with the port number as entry).

How to Get the Value of The X-Forwarded-For HTTP Header Using HttpServletRequest.getRemoteAddr()

If the HTTP requests are handled by an Apache server and forwarded to Jetty with mod_proxy, the original client IP address is in the X-Forwarded-For header and the HttpServletRequest.getRemoteAddr() will return the address of the Apache proxy.

Jetty has a forwarded property which takes the value from X-Forwarded-For and places it in the HttpServletRequest remoteAddr property. This property is not available directly through the endpoint configuration but it can be easily added using the socketConnectors property:

This is particularly useful when an existing Apache server handles TLS connections for a domain and proxies them to application servers internally.

Default Behavior for Returning HTTP Status Codes

The default behavior of HTTP status codes is defined by the org.apache.camel.component.http.DefaultHttpBinding class, which handles how a response is written and also sets the HTTP status code. If the exchange was processed successfully, the 200 HTTP status code is returned. If the exchange failed with an exception, the 500 HTTP status code is returned, and the stacktrace is returned in the body. If you want to specify which HTTP status code to return, set the code in the Exchange.HTTP_RESPONSE_CODE header of the OUT message.

Customizing HttpBinding

By default, Camel uses the org.apache.camel.component.http.DefaultHttpBinding to handle how a response is written. If you like, you can customize this behavior either by implementing your own HttpBinding class or by extending DefaultHttpBinding and overriding the appropriate methods.

The following example shows how to customize the DefaultHttpBinding in order to change how exceptions are returned:{snippet:id=e1|lang=java|url=camel/trunk/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/HttpBindingRefTest.java}We can then create an instance of our binding and register it in the Spring registry as follows:

If you need more handlers, set the handlers option equal to a comma-separated list of bean IDs.

How to Customize the Response on an HTTP 500 Server Error

You may want to return a custom reply message when something goes wrong, instead of the default reply message Camel Jetty replies with. You could use a custom HttpBinding to be in control of the message mapping, but often it may be easier to use Camel's Exception Clause to construct the custom reply message.

Multi-Part Form Support

From Camel 2.3.0: camel-jetty support to multi-part form post out of box. The submitted form-data are mapped into the message header. camel-jetty creates an attachment for each uploaded file. The file name is mapped to the name of the attachment. The content type is set as the content type of the attachment file name. You can find the example here.{snippet:id=e1|lang=java|url=camel/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/MultiPartFormTest.java|title=Note: getName() functions as shown below in versions 2.5 and higher. In earlier versions you receive the temporary file name for the attachment instead}

Jetty JMX Support

From Camel 2.3.0: camel-jetty supports the enabling of Jetty's JMX capabilities at the component and endpoint level with the endpoint configuration taking priority.

Note: JMX must be enabled within the Camel context in order to enable JMX support in this component as the component provides Jetty with a reference to the MBeanServer registered with the Camel context.

As the camel-jetty component caches and reuses Jetty resources for a given protocol/host/port pairing, this configuration option will only be evaluated during the creation of the first endpoint to use a protocol/host/port pairing.

Example: given two routes created from the following XML fragments, JMX support would remain enabled for all endpoints listening on: https://0.0.0.0.

The camel-jetty component also provides for direct configuration of the Jetty MBeanContainer. Jetty creates MBean names dynamically. If you are running another instance of Jetty outside of the Camel context and sharing the same MBeanContainer between the instances, you can provide both instances with a reference to the same MBeanContainer in order to avoid name collisions when registering Jetty MBeans.