Page History

h2. Jetty Component

*Supports non blocking* *[Request Reply]* *producer in Camel 2.1 onwards*

The *jetty* component provides HTTP-based [endpoints|Endpoint] for consuming HTTP requests. That is, the Jetty component behaves as a simple Web server.

In *Camel 2.1* the *jetty* component also provides non blocking [Request Reply] for producing HTTP requests. That is it can also acts as HTTP client sending to a remote HTTP server and use non blocking in this process. See more at [ToAsync] and the [HTTP Async Example].

h3. URI format

{code}
jetty:http://hostname[:port][/resourceUri][?options]
{code}

You can append query options to the URI in the following format, {{?option=value&option=value&...}}

h3. Options

|| Name || Default Value || Description ||
| {{sessionSupport}} | {{false}} | Specifies whether to enable the session manager on the server side of Jetty. |
| {{httpClient.XXX}} | {{null}} | *Camel 1.6.0/2.0:* Configuration of Jetty's [HttpClient|http://wiki.eclipse.org/Jetty/Tutorial/HttpClient]. For example, setting {{httpClient.idleTimeout=30000}} sets the idle timeout to 30 seconds. |
| {{httpBindingRef}} | {{null}} | *Camel 1.6.0/2.0:* Reference to an {{org.apache.camel.component.http.HttpBinding}} in the [Registry]. {{HttpBinding}} can be used to customize how a response should be written. |
| {{matchOnUriPrefix}} | {{false}} | *Camel 2.0:* Whether or not the {{CamelServlet}} should try to find a target consumer by matching the URI prefix if no exact match is found. |
| {{handlers}} | {{null}} | *Camel 1.6.1/2.0:* 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). |
| {{chunked}} | {{true}} | *From Camel 2.2:* If this option is false Jetty servlet will disable the HTTP streaming and set the content-length header on the response |
| {{enableJmx}} | {{false}} | *From Camel 2.3:* If this option is true, Jetty JMX support will be enabled for this endpoint. See [Jetty JMX support|#Jetty JMX support] for more details. |

h3. 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-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. This feature was introduced in Camel 1.5.

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

h3. Usage

The Jetty component only supports consumer endpoints. Therefore a Jetty endpoint URI should be used only as the *input* for a Camel route (in a {{from()}} DSL call). To issue HTTP requests against other HTTP endpoints, use the [HTTP Component|HTTP]

h3. Sample

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-jetty/src/test/java/org/apache/camel/component/jetty/JettyRouteTest.java}

{note:title=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.
{note}

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-jetty/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-jetty/src/test/java/org/apache/camel/component/jetty/JettyContentBasedRouteTest.java}
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 [El] or [OGNL]---we could also test for the parameter value and do routing based on the header value as well.

h3. Session Support

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:

{code:xml}
<route><from uri="jetty:http://0.0.0.0/myapp/myservice/?sessionSupport=true"/><processRef ref="myCode"/><route>
{code}

The {{myCode}} [Processor] can be instantiated by a Spring {{bean}} element:

{code:xml}
<bean id="myCode"class="com.mycompany.MyCodeProcessor"/>
{code}

Where the processor implementation can access the {{HttpSession}} as follows:

{code:java}
publicvoid process(Exchange exchange)throwsException { HttpSession session = ((HttpExchange)exchange).getRequest().getSession(); ... }
{code}
h3. SSL Support (HTTPS)

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:

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

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:

*until Camel 2.2*
* {{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 onwards*
* {{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 {{\-storepass}} 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 {{\-keypass}} option).

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

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. There's a slight difference between Camel 1.6.x and 2.x:

*Camel 1.x*
{code}
<bean id="jetty"class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnector"> <bean class="org.mortbay.jetty.security.SslSocketConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="wantClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </property> </bean>
{code}

*until Camel 2.2*
{code}
<bean id="jetty"class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.mortbay.jetty.security.SslSocketConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="needClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </entry> </map> </property> </bean>
{code}


*from Camel 2.3 onwards*
{code}
<bean id="jetty"class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.eclipse.jetty.server.ssl.SslSocketConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="needClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </entry> </map> </property> </bean>
{code}

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

h3. 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 {{HttpProducer.HTTP_RESPONSE_CODE}} header of the OUT message.

h3. Customizing HttpBinding

*Available as of Camel 1.5.1/2.0*

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-jetty/src/test/java/org/apache/camel/component/jetty/JettyHttpBindingRefTest.java}

We can then create an instance of our binding and register it in the Spring registry as follows:
{code:xml}
<bean id="mybinding"class="com.mycompany.MyHttpBinding"/>
{code}

And then we can reference this binding when we define the route:
{code:xml}
<route><from uri="jetty:http://0.0.0.0:8080/myapp/myservice?httpBindingRef=mybinding"/><to uri="bean:doSomething"/></route>
{code}

h3. Jetty handlers and security configuration

*Available as of Camel 1.6.1/2.0:* 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:
{code:xml}
<-- Jetty Security handling --><bean id="userRealm"class="org.mortbay.jetty.plus.jaas.JAASUserRealm"><property name="name"value="tracker-users"/><property name="loginModuleName"value="ldaploginmodule"/></bean><bean id="constraint"class="org.mortbay.jetty.security.Constraint"><property name="name"value="BASIC"/><property name="roles"value="tracker-users"/><property name="authenticate"value="true"/></bean><bean id="constraintMapping"class="org.mortbay.jetty.security.ConstraintMapping"><property name="constraint"ref="constraint"/><property name="pathSpec"value="/*"/></bean><bean id="securityHandler"class="org.mortbay.jetty.security.SecurityHandler"><property name="userRealm"ref="userRealm"/><property name="constraintMappings"ref="constraintMapping"/></bean>
{code}

*And from Camel 2.3 onwards* you can configure a list of Jetty handlers as follows:
{code:xml}
<-- Jetty Security handling --><bean id="constraint"class="org.eclipse.jetty.http.security.Constraint"><property name="name"value="BASIC"/><property name="roles"value="tracker-users"/><property name="authenticate"value="true"/></bean><bean id="constraintMapping"class="org.eclipse.jetty.security.ConstraintMapping"><property name="constraint"ref="constraint"/><property name="pathSpec"value="/*"/></bean><bean id="securityHandler"class="org.eclipse.jetty.security.ConstraintSecurityHandler"><property name="authenticator"><bean class="org.eclipse.jetty.security.authentication.BasicAuthenticator"/></property><property name="constraintMappings"><list><ref bean="constraintMapping"/></list></property></bean>
{code}

You can then define the endpoint as:
{code}
from("jetty:http://0.0.0.0:9080/myservice?handlers=securityHandler")
{code}

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

h3. How to return a custom HTTP 500 reply message

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:
{snippet:id=e1|lang=java|url=camel/trunk/components/camel-jetty/src/test/java/org/apache/camel/component/jetty/JettyOnExceptionHandledTest.java}

h3. Multi-part Form support

From Camel 2.3.0, camel-jetty support to 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.
{snippet:id=e1|lang=java|url=camel/trunk/components/camel-jetty/src/test/java/org/apache/camel/component/jetty/MultiPartFormTest.java}

h3. 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 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".

{code:xml}
<from uri="jetty:https://0.0.0.0/myapp/myservice1/?enableJmx=true"/>
{code}

{code:xml}
<from uri="jetty:https://0.0.0.0/myapp/myservice2/?enableJmx=false"/>
{code}

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


{include:Endpoint See Also}
- [Http]