Jetty

Camel components are configured on two separate levels:

The Jetty component supports 36 options, which are listed below.

The Jetty endpoint is configured using URI syntax:

with the following path and query parameters:

Camel uses the same message headers as the HTTP component. It also uses (Exchange.HTTP_CHUNKED,CamelHttpChunked) header to turn on or turn off the chunked encoding on the camel-jetty 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.

You can get the request.parameter from the message header not only from Get Method, but also other HTTP method.

The Jetty component supports 2 message header(s), which is/are listed below:

The Jetty component supports consumer endpoints.

In this sample we define a route that exposes a HTTP service at http://localhost:8080/myapp/myservice:

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.

To listen across an entire URI prefix, see How do I let Jetty match wildcards.

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.

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.

So if a client sends the 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 (such as OGNL) we could also test for the parameter value and do routing based on the header value as well.

The session support option, sessionSupport, can be used to enable a HttpSession object and access the session object while processing the exchange. For example, the following route enables sessions:

The myCode Processor can be instantiated by a Spring bean element:

Where the processor implementation can access the HttpSession as follows:

Using the JSSE Configuration Utility

The 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.

Programmatic configuration of the component

Spring DSL based configuration of endpoint

Blueprint based configuration of endpoint

Global configuration of sslContextParameters in a dedicated Blueprint XML file

Use of the global configuration in other Blueprint XML files with route definitions

Configuring Jetty Directly

Jetty provides SSL support out of the box. To enable Jetty to run in SSL mode, simply format the URI with the \https:// prefix---for example:

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:

For details of how to configure SSL on a Jetty endpoint, read the following documentation at the Jetty Site: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL

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.

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.

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:

We can then create an instance of our binding and register it in the Spring registry as follows:

And then we can reference this binding when we define the route:

You can configure a list of Jetty handlers on the endpoint, which can be useful for enabling advanced Jetty security features. These handlers are configured in Spring XML as follows:

You can configure a list of Jetty handlers as follows:

You can then define the endpoint as:

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

Blueprint based definition of basic authentication (based on Jetty 12):

The roles.properties files contains

This file is located in the etc folder and will be reloaded when changed. The endpoint

is now secured with basic authentication, only username1 with password1 and username2 with password2 are able to access the endpoint.

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. For example as show here, where we return Dude something went wrong with HTTP error code 500:

The camel-jetty component supports multipart 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.

The camel-jetty component supports the enabling of Jetty’s JMX capabilities at the component and endpoint level with the endpoint configuration taking priority. Note that 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. Because 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. For 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 MBeanServer 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.