You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Jetty Component

The jetty: component provides HTTP based endpoints for consuming HTTP requests that arrive at a http endpoint.

URI format

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

Options

Name

Default Value

Description

sessionSupport

false

The option to enable the session manager in the server side of Jetty.

httpClient.XXX

null

Camel 1.5.1/2.0: Configuration of the HttpClient Jetty uses. So setting httpClient.idleTimeout=30000 will set the idle timeout to 30 seconds.

httpBindingRef

null

Camel 1.5.1/2.0: Reference to a org.apache.camel.component.http.HttpBinding in the Registry. HttpBinding can be used to customize how response should be written.

matchOnUriPrefix

false

Camel 2.0: Whether or not the CamelServlet should try to find a target consumer by matching 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 instance to add security.

Message Headers

Camel will apply the same Message Headers form the HTTP component.

Camel will also populate all request.parameter and request.headers. For instance of a client request with http://myserver/myserver?orderid=123 then the exchange will contain a header named orderid with the value 123. This feature is introduced in Camel 1.5.

Usage

You can only consume from endpoints generated by the Jetty component. Therefore it should only be used as input into your camel Routes. To issue HTTP requests against other HTTP endpoints you can use the HTTP Component

Sample

In this sample we define a route where we expose a http service at http://localhost:8080/myapp/myservice:

Error formatting macro: snippet: java.lang.NullPointerException

Usage of localhost

When specifying localhost in URL Camel will expose the endpoint only on local interface, so it cannot be accessed from outside the machine it operates on.

If an endpoint should be exposed on specific network interface, specific IP address of this interface should be used. If an endpoint should be exposed on all interfaces 0.0.0.0 address should be used.

Our business logic is implemented in our MyBookService class where we can access the http request stuff and return a response.
Note: The assert is because the code is part of an unit test.

Error formatting macro: snippet: java.lang.NullPointerException

In the sample below we have a content based route that routes all requests that contain the URI parameter one to mock:one and all others to mock:other.

Error formatting macro: snippet: java.lang.NullPointerException

So if a client sends the http request: http://serverUri?one=hello then camel-jetty will copy the http request parameter one to the exchange.in.header. Then we can use the simple language to route exchanges that contain this header to a specific endpoint and all others to another. If we used a more powerful language than Simple such as EL or OGNL would could also test for the parameter value and do routing based on the header value as well.

Session Support

Session support can be used to enable HttpSession and being able to get this while processing the exchange.

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

And then we have a Processor that we configure as:

   <bean id="myCode" class="com.mycompany.MyCodeProcessor"/>

And in this processor we can get the HttpSession:

   public void process(Exchange exchange) throws Exception {
     HttpSession session = ((HttpExchange)exchange).getRequest().getSession();
     ...
   }

SSL https Support

Jetty Provides SSL support out of the box. To configure Jetty to run in SSL mode, you simply set the uri to have https:// as the parameter.

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

Jetty will need to know where to load your keystore from and what passwords to use in order to load the correct SSL certificate. The relevant System Properties set will point jetty in the right direction.

For the keystore path, use jetty.ssl.keystore
For the passwords, use jetty.ssl.keypassword and jetty.ssl.password

To create a certificate, and for Password issues, read the following documentation at the Jetty Site.

Default behavior for returning HTTP status codes

Camel will default use org.apache.camel.component.http.DefaultHttpBinding that handles how response is written, and also setting the http status code.

If the exchange could be processed with success http status code 200 is returned. However if the OUT message contains a header HttpProducer.HTTP_RESPONSE_CODE then this code is used instead. To allow end users to set a specific status code.
If the exchange failed with an exception http status code 500 is returned, and the stacktrace is returned in the body.

Customizing HttpBinding

Available as of Camel 1.5.1/2.0

Camel will default use org.apache.camel.component.http.DefaultHttpBinding that handles how response is written.
This behavior can be customized by implementing your own HttpBinding class or extending DefaultHttpBinding and override appropriate methods.

In the sample below we use our own binding to change how exceptions should be returned:

Error formatting macro: snippet: java.lang.NullPointerException

Then we can have our binding registered in the registry as:

   <bean id="mybinding" class="com.mycompany.MyHttpBinding"/>

And then we can refer to this binding when we configure the route:

   <route>
     <from uri="jetty:http://0.0.0.0:8080/myapp/myservice?httpBindingRef=mybinding"/>
     <to uri="bean:doSomething"/>
   </route>

Jetty Handlers for e.g. security

Available as of Camel 1.6.1/2.0 you can configure a list of handlers on the endpoint. These handlers could be configured in Spring XML as:

        <-- 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 then you could define the endpoint as:

from("jetty:http://0.0.0.0:9080/myservice?handlers=securityHandler")

If you need more handlers then just add another separated with comma.

See Also

  • No labels