Jetty Component
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 a http client which mean you can also use it with Camel as a producer.
Stream
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 data multiple times (eg: doing multicasting, or redelivery 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 will need to add the following dependency to their pom.xml
for this component:
<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]
You can append query options to the URI in the following format, ?option=value&option=value&...
Options
Name |
Default Value |
Description |
---|---|---|
|
|
Specifies whether to enable the session manager on the server side of Jetty. |
|
|
Configuration of Jetty's HttpClient |
|
|
To use a shared |
|
|
Camel 2.11: Producer only: To set a value for minimum number of threads in |
|
|
Camel 2.11: Producer only: To set a value for maximum number of threads in |
|
|
Reference to an |
|
|
Camel 2.6.0+: Reference to an |
|
|
Whether or not the |
|
|
Specifies a comma-delimited set of |
|
|
Camel 2.2: If this option is false Jetty servlet will disable the HTTP streaming and set the content-length header on the response |
|
|
Camel 2.3: If this option is true, Jetty JMX support will be enabled for this endpoint. See Jetty JMX support for more details. |
|
|
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 |
|
|
Option to disable throwing the |
|
|
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 |
|
|
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.5: Whether Jetty |
|
|
Camel 2.6: Allows using a custom multipart filter. Note: setting |
|
|
Camel 2.9: Allows using a custom filters which is putted into a list and can be find in the Registry |
|
|
Camel 2.6: Allows to set a timeout in millis when using Jetty as consumer (server). By default Jetty uses 30000. You can use a value of |
|
|
Camel 2.6: Whether or not to use Jetty continuations |
|
|
Camel 2.8: Reference to a |
|
|
Specifies whether to enable HTTP TRACE for this Jetty consumer. By default TRACE is turned off. |
|
|
Camel 2.11: Reference to a instance of |
|
|
Camel 2.11: Producer only Refers to a custom |
|
|
Camel 2.12: To use a custom buffer size on the |
|
|
Camel 2.11: Producer only The http proxy Host url which will be used by Jetty client. |
|
|
Camel 2.11: Producer only The http proxy port which will be used by Jetty client. |
|
|
Camel 2.13: if the option is true, jetty will send the server header with the jetty version information to the client which sends the request. NOTE please make sure there is no any other camel-jetty endpoint is share the same port, otherwise this option may not work as expected. |
|
|
Camel 2.14: if the option is true, jetty server will send the date header to the client which sends the request. NOTE please make sure there is no any other camel-jetty endpoint is share the same port, otherwise this option may not work as expected. |
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.
Starting with Camel 2.2.0, you can get the request.parameter from the message header not only from Get 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
Component Options
The JettyHttpComponent
provides the following options:
Name |
Default Value |
Description |
---|---|---|
|
|
Camel 2.3: If this option is true, Jetty JMX support will be enabled for this endpoint. See Jetty JMX support for more details. |
|
|
Consumer only: The password for the keystore when using SSL. |
|
|
Consumer only: The password when using SSL. |
|
|
Consumer only: The path to the keystore. |
|
|
Camel 2.5 Consumer only: To set a value for minimum number of threads in server thread pool. Notice that both a min and max size must be configured. |
|
|
Camel 2.5 Consumer only: To set a value for maximum number of threads in server thread pool. Notice that both a min and max size must be configured. |
|
|
Camel 2.5 Consumer only: To use a custom thread pool for the server. This option should only be used in special circumstances. |
|
|
Camel 2.3 Consumer only: A map which contains per port number specific SSL connectors. See section SSL support for more details. |
|
|
Camel 2.5 Consumer only: A map which contains per port number specific HTTP connectors. Uses the same principle as |
|
|
Camel 2.5 Consumer only. A map which contains general SSL connector properties. See section SSL support for more details. |
|
|
Camel 2.5 Consumer only. A map which contains general HTTP connector properties. Uses the same principle as |
|
|
Deprecated: Producer only: To use a custom |
|
|
Producer only: To set a value for minimum number of threads in |
|
|
Producer only: To set a value for maximum number of threads in |
|
|
Deprecated: Producer only: To use a custom thread pool for the client. This option is removed from Camel 2.11 onwards. |
|
|
Camel 2.8: To configure a custom SSL/TLS configuration options at the component level. See Using the JSSE Configuration Utility for more details. |
|
|
Camel 2.11.2: Allows to configure a custom value of the request buffer size on the Jetty connectors. |
|
|
Camel 2.11.2: Allows to configure a custom value of the request header size on the Jetty connectors. |
|
|
Camel 2.11.2: Allows to configure a custom value of the response buffer size on the Jetty connectors. |
|
|
Camel 2.11.2: Allows to configure a custom value of the response header size on the Jetty connectors. |
|
|
Camel 2.12.2/2.11.3 To use a http proxy. |
|
|
Camel 2.12.2/2.11.3: To use a http proxy. |
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("jetty://http://www.google.com");
or in Spring XML
<route> <from uri="direct:start"/> <to uri="jetty://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
:
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.
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 EL or OGNL--we could also test for the parameter value and do routing 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. For example, the following route enables sessions:
<route> <from uri="jetty:http://0.0.0.0/myapp/myservice/?sessionSupport=true"/> <processRef ref="myCode"/> <route>
The myCode
Processor can be instantiated by a Spring bean
element:
<bean id="myCode"class="com.mycompany.MyCodeProcessor"/>
Where the processor implementation can access the HttpSession
as follows:
public void process(Exchange exchange) throws Exception { HttpSession session = exchange.getIn(HttpMessage.class).getRequest().getSession(); ... }
SSL Support (HTTPS)
Using the JSSE Configuration Utility
As of Camel 2.8, 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
KeyStoreParameters ksp = new KeyStoreParameters(); ksp.setResource("/users/home/server/keystore.jks"); ksp.setPassword("keystorePassword"); KeyManagersParameters kmp = new KeyManagersParameters(); kmp.setKeyStore(ksp); kmp.setKeyPassword("keyPassword"); SSLContextParameters scp = new SSLContextParameters(); scp.setKeyManagers(kmp); JettyComponent jettyComponent = getContext().getComponent("jetty", JettyComponent.class); jettyComponent.setSslContextParameters(scp);
Spring DSL based configuration of endpoint
... <camel:sslContextParameters id="sslContextParameters"> <camel:keyManagers keyPassword="keyPassword"> <camel:keyStore resource="/users/home/server/keystore.jks" password="keystorePassword"/> </camel:keyManagers> </camel:sslContextParameters>... ... <to uri="jetty:https://127.0.0.1/mail/?sslContextParametersRef=sslContextParameters"/> ...
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:
<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:
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 thekeystore
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 thekeystore
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 thekeystore
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 thekeystore
command's-keypass
option).
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. There's a slight difference between the various Camel versions:
Up to Camel 2.2
<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>
Camel 2.3, 2.4
<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>
*From Camel 2.5 we switch to use SslSelectChannelConnector *
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector"> <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>
The value you use as keys in the above map is the port you configure Jetty to listen on.
Configuring general SSL properties
Available as of 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).
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectorProperties"> <map> <entry key="password"value="..."/> <entry key="keyPassword"value="..."/> <entry key="keystore"value="..."/> <entry key="needClientAuth"value="..."/> <entry key="truststore"value="..."/> </map> </property> </bean>
How to obtain reference to the X509Certificate
Jetty stores a reference to the certificate in the HttpServletRequest which you can access from code as follows:
HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class); X509Certificate cert = (X509Certificate) req.getAttribute("javax.servlet.request.X509Certificate")
Configuring general HTTP properties
Available as of 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).
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="socketConnectorProperties"> <map> <entry key="acceptors" value="4"/> <entry key="maxIdleTime" value="300000"/> </map> </property> </bean>
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.
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:
We can then create an instance of our binding and register it in the Spring registry as follows:
<bean id="mybinding"class="com.mycompany.MyHttpBinding"/>
And then we can reference this binding when we define the route:
<route><from uri="jetty:http://0.0.0.0:8080/myapp/myservice?httpBindingRef=mybinding"/><to uri="bean:doSomething"/></route>
Jetty handlers and security configuration
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:
<-- 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>
And from Camel 2.3 onwards you can configure a list of Jetty handlers as follows:
<-- 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>
You can then define the endpoint as:
from("jetty:http://0.0.0.0:9080/myservice?handlers=securityHandler")
If you need more handlers, set the handlers
option equal to a comma-separated list of bean IDs.
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:
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.
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".
<from uri="jetty:https://0.0.0.0/myapp/myservice1/?enableJmx=true"/>
<from uri="jetty:https://0.0.0.0/myapp/myservice2/?enableJmx=false"/>
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.