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
