[CONF] Apache Camel: Jetty (page edited)

Tue, 30 Dec 2008 02:17:38 -0800

Page Edited : CAMEL : Jetty

Jetty has been edited by Claus Ibsen (Dec 30, 2008).

(View changes)

Content:

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. 






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.



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. http://docs.codehaus.org/display/JETTY/How+to+configure+SSL



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:




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