Questions about camel-jetty

[Pete Mueller <pe...@routecloud.com>]

Hello all, 

I am currently working with the camel-jetty integration for hosting some web
services.  During my implementation, I've found a few "oddities" that I
thought I would post here before opening actual bug reports. (NOTE: I am
using Camel 2.0)

1. When an exchange is create from a Jetty endpoint, the BodyType (as
reported via TraceInterceptor) is org.mortbay.jetty.HttpParser.Input.
Processing this data allows me to call getBody(String.class) to get the POST
contents or getBody(HttpServletRequest.class) to get the request object.
However, this is only available to the first processor after the "from"
element.  Subsequent processor calls to getBody(HttpServletRequest.class)
return null, which seem to  be caused because the BodyType was translated to
a InputStreamCache somewhere.  I've tried various methods of passing the
message in to the message out, but I cannot avoid this conversion and loss
of request object.  Is this intended behavior?  If so, how do I get the
request object back?

2. As my exchange moved through the route, I add and remove various headers
using getOut().setHeader(x, y)  as Jetty attaches these headers to the
outgoing message, I would like to remove them, but I am unable to do so. 
I've tried creating what I thought to be an "empty" message using
exchange.getOut() (with no setOut() before-hand) and tried clearing the
headers with something like exchange.getOut().setHeaders(new HashMap<...>()) 
When I look at the TraceInterceptor the headers are not there, but when I
receive the reply from Jetty, the header are still in the response.  Is
there some other mechanism for removing headers from the Jetty response?

3. More of a question than an issue.  If I understand correctly, processors
are chained together, that is, the out message of one processor, becomes the
in message of the next processor.  As I process I frequently need a storage
mechanism for moving data between processors, as the message is processed. 
I usually use headers for this.  Inevitably this means the first line of my
processors are exchange.setOut(exchange.getIn()) to pass info along.  This
is prone to error as if one of my many processors forgets this line,
processors further down the line lose basically everything that was done
before.  I am wondering if there is an alternative In/Out pattern, where the
in and out message stay consistent as they are passed to each processor.  In
this model It may even be acceptable to make the in message immutable.  The
idea is that the processors can build up a single "out message" using the
data from previous processors, but always having access to the original
request in the in message.

Thanks for all your help.
-pete
-- 
View this message in context: http://old.nabble.com/Questions-about-camel-jetty-tp27509400p27509400.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Questions about camel-jetty

[Willem Jiang <wi...@gmail.com>]

Pete Mueller wrote:
> Hello all, 
> 
> I am currently working with the camel-jetty integration for hosting some web
> services.  During my implementation, I've found a few "oddities" that I
> thought I would post here before opening actual bug reports. (NOTE: I am
> using Camel 2.0)
> 
> 1. When an exchange is create from a Jetty endpoint, the BodyType (as
> reported via TraceInterceptor) is org.mortbay.jetty.HttpParser.Input.
> Processing this data allows me to call getBody(String.class) to get the POST
> contents or getBody(HttpServletRequest.class) to get the request object.
> However, this is only available to the first processor after the "from"
> element.  Subsequent processor calls to getBody(HttpServletRequest.class)
> return null, which seem to  be caused because the BodyType was translated to
> a InputStreamCache somewhere.  I've tried various methods of passing the
> message in to the message out, but I cannot avoid this conversion and loss
> of request object.  Is this intended behavior?  If so, how do I get the
> request object back?

If you take a look at camel-jetty code, you will find the camel-jetty 
use a customer Message HttpMessage[1] to store the Request and Response 
object, and Camel just copies the message header and message body 
between the endpoints, so you can't get the HttpServletRequest form the 
message.
You can work around this issue by storing the Request object into the 
message header or exchange property in a customer processor just after 
the jetty endpoint.

I think we need to fix this kind of issue, by removing the HttpMessage 
from the camel-http.

[1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-http/src/main/java/org/apache/camel/component/http/HttpMessage.java

> 
> 2. As my exchange moved through the route, I add and remove various headers
> using getOut().setHeader(x, y)  as Jetty attaches these headers to the
> outgoing message, I would like to remove them, but I am unable to do so. 
> I've tried creating what I thought to be an "empty" message using
> exchange.getOut() (with no setOut() before-hand) and tried clearing the
> headers with something like exchange.getOut().setHeaders(new HashMap<...>()) 
> When I look at the TraceInterceptor the headers are not there, but when I
> receive the reply from Jetty, the header are still in the response.  Is
> there some other mechanism for removing headers from the Jetty response?
> 

I think you need to try out Camel 2.1/0 or coming up Camel 2.2.0, if I 
remember right , we fix this kind message header copy error month ago.

Please feel free to log a JIRA if that kind of error is still there.

> 3. More of a question than an issue.  If I understand correctly, processors
> are chained together, that is, the out message of one processor, becomes the
> in message of the next processor.  As I process I frequently need a storage
> mechanism for moving data between processors, as the message is processed. 
> I usually use headers for this.  Inevitably this means the first line of my
> processors are exchange.setOut(exchange.getIn()) to pass info along.  This
> is prone to error as if one of my many processors forgets this line,
> processors further down the line lose basically everything that was done
> before.  I am wondering if there is an alternative In/Out pattern, where the
> in and out message stay consistent as they are passed to each processor.  In
> this model It may even be acceptable to make the in message immutable.  The
> idea is that the processors can build up a single "out message" using the
> data from previous processors, but always having access to the original
> request in the in message.

There were long discussion about the in out message, you can find that 
thread by search subject "[DISCUSS] Semantics of IN and OUT" in camel 
dev mail list.
> 
> Thanks for all your help.
> -pete

Willem

Re: Questions about camel-jetty

[Wayne Keenan <wa...@gmail.com>]

On Tue, Feb 9, 2010 at 2:03 AM, Pete Mueller <pe...@routecloud.com> wrote:

>
> Hello all,
>
> I am currently working with the camel-jetty integration for hosting some
> web
> services.  During my implementation, I've found a few "oddities" that I
> thought I would post here before opening actual bug reports. (NOTE: I am
> using Camel 2.0)
>
> 1. When an exchange is create from a Jetty endpoint, the BodyType (as
> reported via TraceInterceptor) is org.mortbay.jetty.HttpParser.Input.
> Processing this data allows me to call getBody(String.class) to get the
> POST
> contents or getBody(HttpServletRequest.class) to get the request object.
> However, this is only available to the first processor after the "from"
> element.  Subsequent processor calls to getBody(HttpServletRequest.class)
> return null, which seem to  be caused because the BodyType was translated
> to
> a InputStreamCache somewhere.  I've tried various methods of passing the
> message in to the message out, but I cannot avoid this conversion and loss
> of request object.  Is this intended behavior?  If so, how do I get the
> request object back?
>


I think you are describing the same problem I found; a fix went into
2.2-snapshot:  https://issues.apache.org/activemq/browse/CAMEL-2386

Regards
Wayne


> Thanks for all your help.
> -pete
> --
> View this message in context:
> http://old.nabble.com/Questions-about-camel-jetty-tp27509400p27509400.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>