For your first question, you may take a look at the code of
MessageSupport copy() and copyFrom().

For the second question, it's the stream caching issue, we disable the
stream caching by default in Camel 2.x to improve the performance, and
you can enable it as you want[1]



Pete Mueller wrote:
Hello all,

Note: I am using Camel 2.0

I have recently create a custom component that consumes text off a telnet
session, packages it into a Message class extended from DefaultMessage. The
messages are sent down a route through 3 processors. The problem I am
having is that after the first process completes, the body (and just the
body) of the message when it arrives at the second processor is empty. I
have check over all of my code and I do not manipulate any part of the
exchange in the first processor, other than performing
exchange.setOut(exchange.getIn()) What makes this more interesting, is that
when the message is created the body is a Map containing many name/value
pairs, along with about 5 header fields. When the message enters the second
processor, the header are still there, but the map has been emptied. It has
not been NULLed, but emptied.

I'm guessing that camel is creating a new instance of my custom message
(which has an empty Map by default) but is not transfering the body from the
old message. I'm not sure why camel would be creating a new message in the
first place. Does anyone have some guidance as to what may be causing this?

I will mention another oddity with my routes as I think they may be related.
I have since the beginning had the "trace" option on my routes during
testing. When I began to move to production, I turned off the trace, and
saw that my processors stopped working. I traced it down to the fact that
jetty when receiving an inbound web request creates a message of type
org.mortbay.jetty.HttpParser.Input. When trace is on, I receive this
message with a BodyType of
org.apache.camel.converter.stream.InputStreamCache, with trace off, I
receive the Input class. As my processors expected an InputStream, they
broke. I am guessing that the TraceInterceptor performs a conversion on the
body before logging it. But now I am stuck, I could find a way to convert an
HttpParser.Input to something I can use, but my code has have to have
conditional checks for each class, depending whether trace is on or off. I
also wonder if the TraceInterceptor is affecting my custom messages in a way
that is causing them to disappear.

Is this expected behavior, and if so, what is the recommended solution to
dealing with it?

Thanks for your help

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupusers @
postedMar 8, '10 at 6:11p
activeMar 9, '10 at 1:18a

2 users in discussion

Pete Mueller: 1 post Willem Jiang: 1 post



site design / logo © 2022 Grokbase