Hi,
Why did you need set the message body to be null ?
Will you route the message to the other queue ?
As you know camel has it's Message wrapper for all the other components'
message, we may extend the DefaultMessage to hold the reference of under
layer's component message, If you want deal w
Hi Willem,
Your reply is much appreciated. See my comments below to your questions.
On Fri, Jul 31, 2009 at 4:53 PM, Willem Jiang wrote:
> Hi,
>
> Why did you need set the message body to be null ?
I would expect that camel producers have the chance to treat a "" body
and null body differently i
I'm using Camel Mail to route email messages to a handler. Works
perfectly...but I've bumped into an issue whenever somebody sends an email
with an unsupported charset. For example:
Content-type: text/plain; charset=ansi_x3.110-1983
...and since JDK6 has no idea wtf charset that is, I get
If Camel encounters an exception it will invoke on the error handler
which by default in 1.x tries to reprocess.
If all that fails, the message remains unprocessed. What you need is
to handle the exception yourself and process it any way you want,
either delete it or move it to some other fol
Available now.
Thanks!
Mark
msjwhite wrote:
>
> Can we get the camel-spring-2.0-M3.xsd uploaded to
>
> http://camel.apache.org/schema/spring/
>
> as it appears to be missing at present?
>
> Thanks
> Mark
>
--
View this message in context:
http://www.nabble.com/2.0-M3-Spring-XSD-Missi
I am trying to go through:
http://camel.apache.org/tutorial-jmsremoting.html
I have downloaded the source, and have been able to run the server with an
installed version of AMQ. then I tried to create a JUnit test in stead of
the CamelClientRemoting.class
What I need some help with, is to unders
http://camel.apache.org/tutorial-jmsremoting.html
I start the server up in 1 cmd window.
Then I start another cmd window and run the client
*[mple.client.CamelClient.main()] JmsProducerDEBUG Reply
recieved. Setting reply as OUT message: 66
*
In the server, I get this error:
Hi all,
We currently have a problem where messages that can't be read properly get
dropped instead of being put into a dlq. I have an errorHandler that works
properly when the exception is thrown from within the route (from a
processor for example), but refuses to kick in when it's a lower level