Hi
I do think they are from the underlying JMS Message. The JMS component
in Camel is a bit special as it leverages the JMS properties from the
real javax.jms.Message object. So these properties does only exist in
the javax.jms.Message object that resides in the JmsExchange.
And I do not think yo
Bob,
This scenario should definitely work. I regularly use Camel inside
ServiceMix with customers and most of the flows there are with InOnly
exchanges. I've just added a few lines to a unit test of ours as
well, so it reads:
from("jbi:service:urn:test:forward").to("jbi:service:urn:test:in-only
Hi,
I just wrote a simple unit test which was based on your case in Camel
2.0 trunk.
The code works for me, please feel free to check it[1] out.
[1]
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/language/XPathFunctionTest.java?view=diff&r1=778973&r2=778974&pat
Hi,
Maybe you can write a processor which only copies the message header
that you want.
public void process(final Exchange exchange) {
Message in = exchange.getIn();
Map headers = in.getHeaders();
Message out = exchange.getOut();
// copy the in message header to out message header
Hi,
In Camel 2.0, there are some improvements in the camel-file component.
You can specify the File name by using the File Language expression.
The route rule in camel 2.0 could be
from("file://inbox?move=done/${file:name}").to("file://outputdir");
Please check out these wiki pages[1][2] for mor
Has anyone gotten an in-only JBI exchange to work? If I send a message to
"jbi:service:foo:bar?mep=in-only", it works, but the exchange never seems to
complete. That is, I can only do this once.
Is this a bug, or am I doing something wrong? If anyone has a working
example of sending to a JBI in-o
Claus:
I believe many components have the option of setting timeout. HTTPClient
used by HTTP component internally have a timeout setting
(HttpConnectionParams.setConnectionTimeout():
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/HttpConnectionParams.html#setConn
Claus:
Using tracer, I could figure out where the problem is. It seems like these
unsafe headers are coming from the JMSDestination header deserialization:
JMSDestination=Sun Java System MQ Destination
getName(): DeliveryChannel0Q
Class: com.sun.messaging.BasicQueue
This is my first use of camel so it could be something dumb I'm doing but
this works in version 1.6.1 but fails in 2.0-M1. Here's the pom file:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://
Hi,
I've tried with NodeList in the Camel configure() method :
from("direct:start").setProperty("Addresses").xpath("//Address",
NodeList.class)
.process(myCamelProcessor);
In the Process(Exchange ex) method I got a ClassCastException when I tried
to get values :
NodeList adresses = (NodeList)ex.ge
Hi
On Thu, May 21, 2009 at 9:49 PM, harinair wrote:
>
> I am using Camel to send messages from a Queue to external vendors. The
> protocol can be FTP/SFTP/HTTP or HTTPS. However sometimes the queue starts
> filling up which means that the messages are not getting drained. My feeling
> is the con
Hi
Just for the record the issue with camel-ftp not being thread safe for
concurrency producers to the *same* endpoint have been fixed.
With the recent commit we got a connection pool as well so the ftp
producers do not need to login when reused.
On Mon, May 25, 2009 at 8:20 AM, Claus Ibsen w
Hi
On Tue, May 26, 2009 at 1:29 PM, Jörn Kottmann wrote:
> Hello,
>
> I am running a camel route which consumes messages
> with a durable subscriber from an ActiveMQ topic
> in an OSGi server. The route is like I described it in my last post
> http://www.nabble.com/Problems-with-error-handling-in
Hello,
I am running a camel route which consumes messages
with a durable subscriber from an ActiveMQ topic
in an OSGi server. The route is like I described it in my last post
http://www.nabble.com/Problems-with-error-handling-in-transactional-client-td23706098.html.
When the OSGi server is restar
Claus Ibsen wrote:
Hi
Yeah TX and error handling is hard.
For background on error handling in Camel start from here:
http://camel.apache.org/error-handling-in-camel.html
Basically you cannot use TX with DeadLetterChannel.
All redelivery and whatnot is totally in the hands of the backing system
15 matches
Mail list logo
