[CONF] Apache Camel: Jetty (page edited)

Fri, 21 Nov 2008 10:32:39 -0800

Page Edited : CAMEL : Jetty

Jetty has been edited by Claus Ibsen (Nov 21, 2008).

(View changes)

Content:

Jetty Component

The jetty: component provides HTTP based endpoints for consuming HTTP requests that arrive at an 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. 






Message Headers


Camel will add the following headers to the input message on the exchange






 header 
 description 




 http.requestMethod 
 The request method: POST, GET, PUT, etc. 




 org.apache.camel.component.http.query 
 The HTTP query string (request.getQueryString) 






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:




from("jetty:http://localhost:8080/myapp/myservice").process(new MyBookService());





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.




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(true).setBody("<html><body>Book 123 is Camel in Action</body></html>");
    }
}





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.




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



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:




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");
    }
}





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>





See Also

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

Reply via email to