Jetty ComponentSupports non blocking Request Reply producer in Camel 2.1 onwards The jetty component provides HTTP-based endpoints 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. 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
Message HeadersCamel uses the same message headers as the HTTP component. 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. UsageThe 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 SampleIn this sample we define a route that exposes a HTTP service at http://localhost:8080/myapp/myservice: from("jetty:http://localhost:9080/myapp/myservice").process(new MyBookService());
Our business logic is implemented in the MyBookService class, which accesses the HTTP request contents and then returns a response. public class MyBookService implements Processor { public void process(Exchange exchange) throws Exception { // just get the body as a string String body = exchange.getIn().getBody(String.class); // we have access to the HttpServletRequest here and we can grab it if we need it HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class); assertNotNull(req); // for unit testing assertEquals("bookid=123", body); // send a html response exchange.getOut().setBody("<html><body>Book 123 is Camel in Action</body></html>"); } } 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. from("jetty:" + serverUri) .choice() .when().simple("in.header.one").to("mock:one") .otherwise() .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 SupportThe 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 = ((HttpExchange)exchange).getRequest().getSession(); ... } 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:
<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:
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 Default behavior for returning HTTP status codesThe 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. Customizing HttpBindingAvailable 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: public class MyHttpBinding extends DefaultHttpBinding { @Override public void doWriteExceptionResponse(Throwable exception, HttpServletResponse response) throws IOException { // we override the doWriteExceptionResponse as we only want to alter the binding how exceptions is // written back to the client. // we just return HTTP 200 so the client thinks its okay response.setStatus(200); // and we return this fixed text response.getWriter().write("Something went wrong but we dont care"); } } 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 configurationAvailable 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:
<-- 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>
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. See Also |
