Re: Camel Exchange Patters
Thanks Willem and Claus,
I guess we should only bother with in messages then and forget about the out
message if we want a simple rule.
I thought that the rationale for having both in- and out messages was that
the original in message would be kept unaltered while the out message would
gradually be transformed when passing through the pipeline. I assume now
that you only have access to the message as it was transformed by the
previous processor in the chain. The original message is not available - or
is it?
/Bengt
2010/9/14 Willem Jiang willem.ji...@gmail.com
On 9/11/10 10:03 PM, Christian Müller wrote:
Hello list!
I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
Camel site [1]. I also hat a short conversation with Ade from Progress
about
the exchange pattern, but still I have the feeling I doesn't understand
all
aspects. May be you can help me to understand it correct. Here are my
questions:
- In the book and the Camel site only the exchange patterns InOut and
InOnly
are mentioned but org.apache.camel.ExchangePattern defines the following
exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
- If I understood Ade correct, after each processing on a
component/processor the message goes throught the pipieline before it
receives the next component/processor. In the case of an InOut exchange,
the
pipeline will copy the out message body, headers and attachments into the
in
message. So that in the next component/processor can access these data
from
the in message again. If I use the InOnly exchange pattern, the
component/processor will write the response into the in message and the
pipeline has nothing to copy.
The pipeline always uses a new copy of exchange which will create a new
inMessage copy as you described, if you are using InOnly exchange pattern,
pipeline still create a new Exchange and copy the in message from the first
exchange.
The InOnly and InOut exchange patterns always take effect in the component
side, current DefaultExchange will not check the exchange pattern and will
create a new out message which copy from the exchange in message when you
call the Exchange.getOutMessage().
From the end user perspective it looks like it
doesn't matter, whether to use the InOnly or InOut exchange pattern.
- The only one component I know which handle InOnly and InOut really
defferently is the jms-component. It will only send a reply message if the
exchange pattern InOut is used.
- If I use a InOnly exchange for the following routes, I takes also more
than 5 seconds until my templeate.send() method returns. I would expect
that
the call returns after the exchange was placed into the next sub route
(after a few milliseconds). My key point here is not to improve the
performance. Only to understand the exchange pattern correct, how the work
and how they are used in the right way...
from(direct:start)
.to(direct:sub);
from(direct:sub)
.process(*new* Processor() {
@Override
*public* *void* process(Exchange exchange) *
throws* Exception {
Thread.*sleep*(5000);
}
})
.to(mock:result);
- Do you have recommendations when to use InOnly and InOut?
There are some description about InOnly and InOut message echange pattern
in the Camel in Action chapter 10, as the sync and async invocation. You may
take a look.
- If we write our own processor which modifies the in message, should they
write the modified body into the out message, if the exchnage is out
capable
(and also copy all header and attachments we need for further processing)?
Or should we always modify the in message because it requires less action?
You can modify the in message directly, or do some change on the out
message and the pipeline will pick up the right modified message for you.
The DefaultExchange will create a new out message based on the in message if
you call the Exchange.getOutMessage(), so you don't need to copy the all the
headers and attachments yourself.
- The same question for our own type converters. I know the type converter
is implemented in this way, that it will return the new (converted)
object.
But our type converters also have to modify the message header. Should
they
also check whether the exchange is out capable and than modify the out (if
out capable) or in (if not out capable) message? Is this the way camel
handels the converted object from the type converter?
I think you just need to make the change on the in message, if you want to
avoid the addition copying (camel will copy the out message from the in
message if you make the change on the out message of the exchange).
[1]
Re: Camel Exchange Patters
On Tue, Sep 14, 2010 at 9:02 AM, Bengt Rodehav be...@rodehav.com wrote:
Thanks Willem and Claus,
I guess we should only bother with in messages then and forget about the out
message if we want a simple rule.
I thought that the rationale for having both in- and out messages was that
the original in message would be kept unaltered while the out message would
gradually be transformed when passing through the pipeline. I assume now
that you only have access to the message as it was transformed by the
previous processor in the chain. The original message is not available - or
is it?
No its not avail, unless you fetch if from the UnitOfWork. There is a
feature on the error handler to use the original message when moving a
message to the dead letter channel. Which leverages the UnitOfWork to
fetch it.
In Camel 3.0 we have plans to rework how this works internally
reducing the copying done by the pipeline and make it easier to access
the original message and/or even previous states.
/Bengt
2010/9/14 Willem Jiang willem.ji...@gmail.com
On 9/11/10 10:03 PM, Christian Müller wrote:
Hello list!
I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
Camel site [1]. I also hat a short conversation with Ade from Progress
about
the exchange pattern, but still I have the feeling I doesn't understand
all
aspects. May be you can help me to understand it correct. Here are my
questions:
- In the book and the Camel site only the exchange patterns InOut and
InOnly
are mentioned but org.apache.camel.ExchangePattern defines the following
exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
- If I understood Ade correct, after each processing on a
component/processor the message goes throught the pipieline before it
receives the next component/processor. In the case of an InOut exchange,
the
pipeline will copy the out message body, headers and attachments into the
in
message. So that in the next component/processor can access these data
from
the in message again. If I use the InOnly exchange pattern, the
component/processor will write the response into the in message and the
pipeline has nothing to copy.
The pipeline always uses a new copy of exchange which will create a new
inMessage copy as you described, if you are using InOnly exchange pattern,
pipeline still create a new Exchange and copy the in message from the first
exchange.
The InOnly and InOut exchange patterns always take effect in the component
side, current DefaultExchange will not check the exchange pattern and will
create a new out message which copy from the exchange in message when you
call the Exchange.getOutMessage().
From the end user perspective it looks like it
doesn't matter, whether to use the InOnly or InOut exchange pattern.
- The only one component I know which handle InOnly and InOut really
defferently is the jms-component. It will only send a reply message if the
exchange pattern InOut is used.
- If I use a InOnly exchange for the following routes, I takes also more
than 5 seconds until my templeate.send() method returns. I would expect
that
the call returns after the exchange was placed into the next sub route
(after a few milliseconds). My key point here is not to improve the
performance. Only to understand the exchange pattern correct, how the work
and how they are used in the right way...
from(direct:start)
.to(direct:sub);
from(direct:sub)
.process(*new* Processor() {
�...@override
*public* *void* process(Exchange exchange) *
throws* Exception {
Thread.*sleep*(5000);
}
})
.to(mock:result);
- Do you have recommendations when to use InOnly and InOut?
There are some description about InOnly and InOut message echange pattern
in the Camel in Action chapter 10, as the sync and async invocation. You may
take a look.
- If we write our own processor which modifies the in message, should they
write the modified body into the out message, if the exchnage is out
capable
(and also copy all header and attachments we need for further processing)?
Or should we always modify the in message because it requires less action?
You can modify the in message directly, or do some change on the out
message and the pipeline will pick up the right modified message for you.
The DefaultExchange will create a new out message based on the in message if
you call the Exchange.getOutMessage(), so you don't need to copy the all the
headers and attachments yourself.
- The same question for our own type converters. I know the type converter
is implemented in this way, that it will return the new (converted)
object.
But our type
Re: Camel Exchange Patters
OK, thanks.
/Bengt
2010/9/14 Claus Ibsen claus.ib...@gmail.com
On Tue, Sep 14, 2010 at 9:02 AM, Bengt Rodehav be...@rodehav.com wrote:
Thanks Willem and Claus,
I guess we should only bother with in messages then and forget about the
out
message if we want a simple rule.
I thought that the rationale for having both in- and out messages was
that
the original in message would be kept unaltered while the out message
would
gradually be transformed when passing through the pipeline. I assume now
that you only have access to the message as it was transformed by the
previous processor in the chain. The original message is not available -
or
is it?
No its not avail, unless you fetch if from the UnitOfWork. There is a
feature on the error handler to use the original message when moving a
message to the dead letter channel. Which leverages the UnitOfWork to
fetch it.
In Camel 3.0 we have plans to rework how this works internally
reducing the copying done by the pipeline and make it easier to access
the original message and/or even previous states.
/Bengt
2010/9/14 Willem Jiang willem.ji...@gmail.com
On 9/11/10 10:03 PM, Christian Müller wrote:
Hello list!
I read Claus, Jonathan and Hadrians book Camel in Action and I studied
the
Camel site [1]. I also hat a short conversation with Ade from Progress
about
the exchange pattern, but still I have the feeling I doesn't understand
all
aspects. May be you can help me to understand it correct. Here are my
questions:
- In the book and the Camel site only the exchange patterns InOut and
InOnly
are mentioned but org.apache.camel.ExchangePattern defines the
following
exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and
InOnly?
- If I understood Ade correct, after each processing on a
component/processor the message goes throught the pipieline before it
receives the next component/processor. In the case of an InOut
exchange,
the
pipeline will copy the out message body, headers and attachments into
the
in
message. So that in the next component/processor can access these data
from
the in message again. If I use the InOnly exchange pattern, the
component/processor will write the response into the in message and the
pipeline has nothing to copy.
The pipeline always uses a new copy of exchange which will create a new
inMessage copy as you described, if you are using InOnly exchange
pattern,
pipeline still create a new Exchange and copy the in message from the
first
exchange.
The InOnly and InOut exchange patterns always take effect in the
component
side, current DefaultExchange will not check the exchange pattern and
will
create a new out message which copy from the exchange in message when
you
call the Exchange.getOutMessage().
From the end user perspective it looks like it
doesn't matter, whether to use the InOnly or InOut exchange pattern.
- The only one component I know which handle InOnly and InOut really
defferently is the jms-component. It will only send a reply message if
the
exchange pattern InOut is used.
- If I use a InOnly exchange for the following routes, I takes also
more
than 5 seconds until my templeate.send() method returns. I would expect
that
the call returns after the exchange was placed into the next sub route
(after a few milliseconds). My key point here is not to improve the
performance. Only to understand the exchange pattern correct, how the
work
and how they are used in the right way...
from(direct:start)
.to(direct:sub);
from(direct:sub)
.process(*new* Processor() {
@Override
*public* *void* process(Exchange exchange)
*
throws* Exception {
Thread.*sleep*(5000);
}
})
.to(mock:result);
- Do you have recommendations when to use InOnly and InOut?
There are some description about InOnly and InOut message echange
pattern
in the Camel in Action chapter 10, as the sync and async invocation. You
may
take a look.
- If we write our own processor which modifies the in message, should
they
write the modified body into the out message, if the exchnage is out
capable
(and also copy all header and attachments we need for further
processing)?
Or should we always modify the in message because it requires less
action?
You can modify the in message directly, or do some change on the out
message and the pipeline will pick up the right modified message for
you.
The DefaultExchange will create a new out message based on the in
message if
you call the Exchange.getOutMessage(), so you don't need to copy the all
the
Re: Camel Exchange Patters
Hello Claus!
That's not (in my opinion) how it works currently. At present I work on a
route which looks like this:
errorHandler(
defaultErrorHandler()
.retryAttemptedLogLevel(LoggingLevel.DEBUG)
.retriesExhaustedLogLevel(LoggingLevel.INFO));
onException(IllegalArgumentException.class)
.handled(true)
.maximumRedeliveries(0)
.beanRef(myResultProvider, failureResponse);
from(cxf:bean:MyCoolService)
.processRef(myValidator) // validates conditional rules
.inOut(direct:mySubroute)
.beanRef(myResultProvider, successResponse)
If my validator throws a IllegalArgumentException and the result provider
writes the response into the in message, the web service will return null.
But if I write the response into the out message, the web service will
return it. So, I changes my bean to the following pattern:
if (exchange.getPattern().isOutCapable()) {
exchange.getOut().setBody(response);
} else {
exchange.getIn().setBody(response);
}
And that's the same how the org.apache.camel.processor.ConvertBodyProcessor
works (I know you know this, but for the other guys.. :o) )
public class ConvertBodyProcessor implements Processor {
...
public void process(Exchange exchange) throws Exception {
Message in = exchange.getIn();
if (charset != null) {
exchange.setProperty(Exchange.CHARSET_NAME, charset);
}
Object value = in.getMandatoryBody(type);
if (exchange.getPattern().isOutCapable()) {
Message out = exchange.getOut();
out.copyFrom(in);
out.setBody(value);
} else {
in.setBody(value);
}
}
...
}
Should our custom processors/beans/.. not work in the same way?
Cheers,
Christian
Re: Problem with protobuf example / Spring DSL to unmarshal to protobuf
Let me describe a step-by-step guide so you can recreate it.
Ok, I have constructed a small example using a freshly downloaded copy of
Camel 2.4.0.
I'am using the provided example protobuffer definition from the example:
addressbook.proto and run the protobuffer-compiler protoc to generate the
Java-files
After that created a spring-xml file in the META-INF/spring directory with
the following content:
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd;
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=direct:start/
unmarshal
protobuf
instanceClass=org.apache.camel.dataformat.protobuf.generated.AddressBookProtos$Person
/
/unmarshal
to uri=mock:result/
/route
/camelContext
/beans
Then created a small starter class which started the Camel-main class
(org.apache.camel.spring.Main) and I get the following log with exceptions:
14-sep-2010 10:56:10 org.apache.camel.impl.MainSupport doStart
INFO: Apache Camel 2.4.0 starting
14-sep-2010 10:56:10
org.springframework.context.support.AbstractApplicationContext
prepareRefresh
INFO: Refreshing
org.springframework.context.support.classpathxmlapplicationcont...@1457cb:
startup date [Tue Sep 14 10:56:10 CEST 2010]; root of context hierarchy
14-sep-2010 10:56:10
org.springframework.beans.factory.xml.XmlBeanDefinitionReader
loadBeanDefinitions
INFO: Loading XML bean definitions from file
[D:\projects\CamelProtobufTest\bin\META-INF\spring\camel-protobuf-test.xml]
14-sep-2010 10:56:10 org.apache.camel.impl.MainSupport doStop
INFO: Apache Camel 2.4.0 stopping
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line
12 in XML document from file
[D:\projects\CamelProtobufTest\bin\META-INF\spring\camel-protobuf-test.xml]
is invalid; nested exception is org.xml.sax.SAXParseException:
cvc-complex-type.2.4.a: Invalid content was found starting with element
'protobuf'. One of '{http://camel.apache.org/schema/spring:description,
http://camel.apache.org/schema/spring:aop,
http://camel.apache.org/schema/spring:aggregate,
http://camel.apache.org/schema/spring:bean,
http://camel.apache.org/schema/spring:doCatch,
http://camel.apache.org/schema/spring:when,
http://camel.apache.org/schema/spring:choice,
http://camel.apache.org/schema/spring:otherwise,
http://camel.apache.org/schema/spring:convertBodyTo,
http://camel.apache.org/schema/spring:delay,
http://camel.apache.org/schema/spring:enrich,
http://camel.apache.org/schema/spring:filter,
http://camel.apache.org/schema/spring:doFinally,
http://camel.apache.org/schema/spring:idempotentConsumer,
http://camel.apache.org/schema/spring:inOnly,
http://camel.apache.org/schema/spring:inOut,
http://camel.apache.org/schema/spring:intercept,
http://camel.apache.org/schema/spring:interceptFrom,
http://camel.apache.org/schema/spring:interceptToEndpoint,
http://camel.apache.org/schema/spring:loadBalance,
http://camel.apache.org/schema/spring:log,
http://camel.apache.org/schema/spring:loop,
http://camel.apache.org/schema/spring:marshal,
http://camel.apache.org/schema/spring:multicast,
http://camel.apache.org/schema/spring:onCompletion,
http://camel.apache.org/schema/spring:onException,
http://camel.apache.org/schema/spring:pipeline,
http://camel.apache.org/schema/spring:policy,
http://camel.apache.org/schema/spring:pollEnrich,
http://camel.apache.org/schema/spring:process,
http://camel.apache.org/schema/spring:recipientList,
http://camel.apache.org/schema/spring:removeHeader,
http://camel.apache.org/schema/spring:removeHeaders,
http://camel.apache.org/schema/spring:removeProperty,
http://camel.apache.org/schema/spring:resequence,
http://camel.apache.org/schema/spring:rollback,
http://camel.apache.org/schema/spring:route,
http://camel.apache.org/schema/spring:routingSlip,
http://camel.apache.org/schema/spring:sample,
http://camel.apache.org/schema/spring:setBody,
http://camel.apache.org/schema/spring:setExchangePattern,
http://camel.apache.org/schema/spring:setHeader,
http://camel.apache.org/schema/spring:setOutHeader,
http://camel.apache.org/schema/spring:setProperty,
http://camel.apache.org/schema/spring:sort,
http://camel.apache.org/schema/spring:split,
http://camel.apache.org/schema/spring:stop,
http://camel.apache.org/schema/spring:threads,
http://camel.apache.org/schema/spring:throttle,
http://camel.apache.org/schema/spring:throwException,
http://camel.apache.org/schema/spring:to,
http://camel.apache.org/schema/spring:transacted,
http://camel.apache.org/schema/spring:transform,
Re: Camel Exchange Patters
On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
christian.muel...@gmail.com wrote:
Hello Claus!
That's not (in my opinion) how it works currently. At present I work on a
route which looks like this:
errorHandler(
defaultErrorHandler()
.retryAttemptedLogLevel(LoggingLevel.DEBUG)
.retriesExhaustedLogLevel(LoggingLevel.INFO));
onException(IllegalArgumentException.class)
.handled(true)
.maximumRedeliveries(0)
.beanRef(myResultProvider, failureResponse);
from(cxf:bean:MyCoolService)
.processRef(myValidator) // validates conditional rules
.inOut(direct:mySubroute)
.beanRef(myResultProvider, successResponse)
If my validator throws a IllegalArgumentException and the result provider
writes the response into the in message, the web service will return null.
But if I write the response into the out message, the web service will
return it. So, I changes my bean to the following pattern:
Well that could CXF Bean component having a bug.
If you decide to use a Processor and work on Exchange then you use the
low level Camel API and then you have to handle the IN/OUT stuff
yourself.
if (exchange.getPattern().isOutCapable()) {
exchange.getOut().setBody(response);
} else {
exchange.getIn().setBody(response);
}
And that's the same how the org.apache.camel.processor.ConvertBodyProcessor
works (I know you know this, but for the other guys.. :o) )
public class ConvertBodyProcessor implements Processor {
...
public void process(Exchange exchange) throws Exception {
Message in = exchange.getIn();
if (charset != null) {
exchange.setProperty(Exchange.CHARSET_NAME, charset);
}
Object value = in.getMandatoryBody(type);
if (exchange.getPattern().isOutCapable()) {
Message out = exchange.getOut();
out.copyFrom(in);
out.setBody(value);
} else {
in.setBody(value);
}
}
...
}
Should our custom processors/beans/.. not work in the same way?
Cheers,
Christian
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel Exchange Patters
I think that was very useful information. I hadn't thought of a Processor as
very low level - it's definitely a level that a lot of us will use. Then I
guess that in some circumstances (like when coding a custom processor) you
need to set the out messsage if the MEP is out capable otherwise you just
set the in message. Are there more situations where this is needed?
I think that this subject is definitely complicated enough to warrant a good
documentation somewhere. I think it's really important for developers to
understand core concepts instead of just using boilerplate samples (although
they are very useful).
/Bengt
2010/9/14 Claus Ibsen claus.ib...@gmail.com
On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
christian.muel...@gmail.com wrote:
Hello Claus!
That's not (in my opinion) how it works currently. At present I work on a
route which looks like this:
errorHandler(
defaultErrorHandler()
.retryAttemptedLogLevel(LoggingLevel.DEBUG)
.retriesExhaustedLogLevel(LoggingLevel.INFO));
onException(IllegalArgumentException.class)
.handled(true)
.maximumRedeliveries(0)
.beanRef(myResultProvider, failureResponse);
from(cxf:bean:MyCoolService)
.processRef(myValidator) // validates conditional rules
.inOut(direct:mySubroute)
.beanRef(myResultProvider, successResponse)
If my validator throws a IllegalArgumentException and the result provider
writes the response into the in message, the web service will return
null.
But if I write the response into the out message, the web service will
return it. So, I changes my bean to the following pattern:
Well that could CXF Bean component having a bug.
If you decide to use a Processor and work on Exchange then you use the
low level Camel API and then you have to handle the IN/OUT stuff
yourself.
if (exchange.getPattern().isOutCapable()) {
exchange.getOut().setBody(response);
} else {
exchange.getIn().setBody(response);
}
And that's the same how the
org.apache.camel.processor.ConvertBodyProcessor
works (I know you know this, but for the other guys.. :o) )
public class ConvertBodyProcessor implements Processor {
...
public void process(Exchange exchange) throws Exception {
Message in = exchange.getIn();
if (charset != null) {
exchange.setProperty(Exchange.CHARSET_NAME, charset);
}
Object value = in.getMandatoryBody(type);
if (exchange.getPattern().isOutCapable()) {
Message out = exchange.getOut();
out.copyFrom(in);
out.setBody(value);
} else {
in.setBody(value);
}
}
...
}
Should our custom processors/beans/.. not work in the same way?
Cheers,
Christian
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel Exchange Patters
On Tue, Sep 14, 2010 at 2:16 PM, Bengt Rodehav be...@rodehav.com wrote:
I think that was very useful information. I hadn't thought of a Processor as
very low level - it's definitely a level that a lot of us will use. Then I
guess that in some circumstances (like when coding a custom processor) you
need to set the out messsage if the MEP is out capable otherwise you just
set the in message. Are there more situations where this is needed?
If the MEP is out capable you can still just change the IN message.
If the OUT is null, then Camel will re-use the IN (which you just
changed) and thus still route whatever you have changed.
You only need to use OUT if you want to create a totally 100% new
message which is not related to the IN message at all.
And this is only needed in special cases.
Otherwise you get the problem with: Why do I lose my message headers etc.
I think that this subject is definitely complicated enough to warrant a good
documentation somewhere. I think it's really important for developers to
understand core concepts instead of just using boilerplate samples (although
they are very useful).
/Bengt
2010/9/14 Claus Ibsen claus.ib...@gmail.com
On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
christian.muel...@gmail.com wrote:
Hello Claus!
That's not (in my opinion) how it works currently. At present I work on a
route which looks like this:
errorHandler(
defaultErrorHandler()
.retryAttemptedLogLevel(LoggingLevel.DEBUG)
.retriesExhaustedLogLevel(LoggingLevel.INFO));
onException(IllegalArgumentException.class)
.handled(true)
.maximumRedeliveries(0)
.beanRef(myResultProvider, failureResponse);
from(cxf:bean:MyCoolService)
.processRef(myValidator) // validates conditional rules
.inOut(direct:mySubroute)
.beanRef(myResultProvider, successResponse)
If my validator throws a IllegalArgumentException and the result provider
writes the response into the in message, the web service will return
null.
But if I write the response into the out message, the web service will
return it. So, I changes my bean to the following pattern:
Well that could CXF Bean component having a bug.
If you decide to use a Processor and work on Exchange then you use the
low level Camel API and then you have to handle the IN/OUT stuff
yourself.
if (exchange.getPattern().isOutCapable()) {
exchange.getOut().setBody(response);
} else {
exchange.getIn().setBody(response);
}
And that's the same how the
org.apache.camel.processor.ConvertBodyProcessor
works (I know you know this, but for the other guys.. :o) )
public class ConvertBodyProcessor implements Processor {
...
public void process(Exchange exchange) throws Exception {
Message in = exchange.getIn();
if (charset != null) {
exchange.setProperty(Exchange.CHARSET_NAME, charset);
}
Object value = in.getMandatoryBody(type);
if (exchange.getPattern().isOutCapable()) {
Message out = exchange.getOut();
out.copyFrom(in);
out.setBody(value);
} else {
in.setBody(value);
}
}
...
}
Should our custom processors/beans/.. not work in the same way?
Cheers,
Christian
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel calling commit too early when using split+seda+file endpoint
Is there a link I can use to download 2.5.0 (links on http://camel.apache.org/camel-250-release.html do not work), or I need to go through the code repo? -- View this message in context: http://camel.465427.n5.nabble.com/Camel-calling-commit-too-early-when-using-split-seda-file-endpoint-tp2830894p2839057.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel Exchange Patters
Yeah I remember reading about the problems with losing message headers
somewhere on this list...
To be perfectly honest I think that the number of mails on this thread
indicates the importance of documenting these rules and how things work.
Claus, you are most definitely the man to do it. I've got your book (haven't
read the last updates though) and it certainly warrants a place there.
Perhaps it should also be on the wiki somewhere.
/Bengt
2010/9/14 Claus Ibsen claus.ib...@gmail.com
On Tue, Sep 14, 2010 at 2:16 PM, Bengt Rodehav be...@rodehav.com wrote:
I think that was very useful information. I hadn't thought of a Processor
as
very low level - it's definitely a level that a lot of us will use. Then
I
guess that in some circumstances (like when coding a custom processor)
you
need to set the out messsage if the MEP is out capable otherwise you
just
set the in message. Are there more situations where this is needed?
If the MEP is out capable you can still just change the IN message.
If the OUT is null, then Camel will re-use the IN (which you just
changed) and thus still route whatever you have changed.
You only need to use OUT if you want to create a totally 100% new
message which is not related to the IN message at all.
And this is only needed in special cases.
Otherwise you get the problem with: Why do I lose my message headers etc.
I think that this subject is definitely complicated enough to warrant a
good
documentation somewhere. I think it's really important for developers to
understand core concepts instead of just using boilerplate samples
(although
they are very useful).
/Bengt
2010/9/14 Claus Ibsen claus.ib...@gmail.com
On Tue, Sep 14, 2010 at 10:23 AM, Christian Müller
christian.muel...@gmail.com wrote:
Hello Claus!
That's not (in my opinion) how it works currently. At present I work
on a
route which looks like this:
errorHandler(
defaultErrorHandler()
.retryAttemptedLogLevel(LoggingLevel.DEBUG)
.retriesExhaustedLogLevel(LoggingLevel.INFO));
onException(IllegalArgumentException.class)
.handled(true)
.maximumRedeliveries(0)
.beanRef(myResultProvider, failureResponse);
from(cxf:bean:MyCoolService)
.processRef(myValidator) // validates conditional rules
.inOut(direct:mySubroute)
.beanRef(myResultProvider, successResponse)
If my validator throws a IllegalArgumentException and the result
provider
writes the response into the in message, the web service will return
null.
But if I write the response into the out message, the web service will
return it. So, I changes my bean to the following pattern:
Well that could CXF Bean component having a bug.
If you decide to use a Processor and work on Exchange then you use the
low level Camel API and then you have to handle the IN/OUT stuff
yourself.
if (exchange.getPattern().isOutCapable()) {
exchange.getOut().setBody(response);
} else {
exchange.getIn().setBody(response);
}
And that's the same how the
org.apache.camel.processor.ConvertBodyProcessor
works (I know you know this, but for the other guys.. :o) )
public class ConvertBodyProcessor implements Processor {
...
public void process(Exchange exchange) throws Exception {
Message in = exchange.getIn();
if (charset != null) {
exchange.setProperty(Exchange.CHARSET_NAME, charset);
}
Object value = in.getMandatoryBody(type);
if (exchange.getPattern().isOutCapable()) {
Message out = exchange.getOut();
out.copyFrom(in);
out.setBody(value);
} else {
in.setBody(value);
}
}
...
}
Should our custom processors/beans/.. not work in the same way?
Cheers,
Christian
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: How do YOU handle scheduling?
Hi
I'm now trying to just use a Spring trigger and a simple class using
ConsumerTemplate and ProducerTemplate to fetch the files. However, I can't
get the ConsumerTemplate to stop polling when I first start it, what's going
on?
public class FtpsPoller {
@Autowired
private ConsumerTemplate consumer;
@Autowired
private ProducerTemplate producer;
public void poll() throws Exception {
String ftpsUri =
ftps:{{ftp.address}}{{ftp.path.out}}?username={{ftp.username}}password={{ftp.password}}
String fileUri = file:{{path.out}};
Exchange exchange = null;
do {
exchange = consumer.receive(ftpsUri);
producer.send(fileUri, exchange);
} while(exchange != null);
consumer.stop(); //Doesn't stop anything
}
}
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839061.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel calling commit too early when using split+seda+file endpoint
On Tue, Sep 14, 2010 at 2:27 PM, camel_el eric.ladouc...@cse-cst.gc.ca wrote: Is there a link I can use to download 2.5.0 (links on http://camel.apache.org/camel-250-release.html do not work), or I need to go through the code repo? http://camel.apache.org/download You need to download the jars one by one, eg camel-core and the others as there is no big ZIP file for 2.5-SNAPSHOT. If you use maven it can download all the stuff for you. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-calling-commit-too-early-when-using-split-seda-file-endpoint-tp2830894p2839057.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Camel calling commit too early when using split+seda+file endpoint
I've tried smcduff's patch on 2.4.0 and it fixed my problem. Like he has mentioned on https://issues.apache.org/activemq/browse/CAMEL-3121, we had to modify his original patch slightly to make it work at shutdown time. I'll still give 2.5.0 a try when I get access to it. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-calling-commit-too-early-when-using-split-seda-file-endpoint-tp2830894p2839063.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How do YOU handle scheduling?
Read the java doc and documentation for the ConsumerTemplate.
Or check chapter 3 or appendix C in the Camel book.
On Tue, Sep 14, 2010 at 2:30 PM, Andreas A. andreasasm...@gmail.com wrote:
Hi
I'm now trying to just use a Spring trigger and a simple class using
ConsumerTemplate and ProducerTemplate to fetch the files. However, I can't
get the ConsumerTemplate to stop polling when I first start it, what's going
on?
public class FtpsPoller {
�...@autowired
private ConsumerTemplate consumer;
�...@autowired
private ProducerTemplate producer;
public void poll() throws Exception {
String ftpsUri =
ftps:{{ftp.address}}{{ftp.path.out}}?username={{ftp.username}}password={{ftp.password}}
String fileUri = file:{{path.out}};
Exchange exchange = null;
do {
exchange = consumer.receive(ftpsUri);
producer.send(fileUri, exchange);
} while(exchange != null);
consumer.stop(); //Doesn't stop anything
}
}
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839061.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel calling commit too early when using split+seda+file endpoint
Hi
Can you try 2.5 as it should have been fixed already by another ticket.
On Tue, Sep 14, 2010 at 1:39 PM, Claus Ibsen claus.ib...@gmail.com wrote:
Hi
I have created a ticket to track this
https://issues.apache.org/activemq/browse/CAMEL-3121
On Thu, Sep 9, 2010 at 10:07 PM, camel_el eric.ladouc...@cse-cst.gc.ca
wrote:
This piece of code is a very simplified version of my real code. My
application is running on an OSGi container and the different stages in my
processing are isolated in different bundles. So when I need to pass a
message from one stage to another, I need to use a 'vm' endpoint, a.k.a. a
seda queue.
To give you more background, I am processing large files (each file can
contain up to 500,000 items) and I receive a lot of those. All of my input
is multithreaded, so that I can read many files at the same time.
overview of my real route
from(file:input)
.threads(5)
.bean(ObjectIteratorFactory.class, createIterator) // this bean
creates an iterator that will read 1 item at a time
// and it
will keep the input file opened until it is done
.split(body()).streaming()
.process(firstProcessor)
.to(vm:secondStageInAnotherBundle)
.end()
.log(Done processing file ${file:name})
So that seda queue (or vm endpoint in my case) is needed since I don't want
to have all of my code inside the same bundle. If I don't use a seda queue,
it works fine and the file gets deleted at then end, when ObjectIterator has
closed its input stream. If the seda is involved, Camel tries to close the
file after processing the first item in the file...
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-calling-commit-too-early-when-using-split-seda-file-endpoint-tp2830894p2834071.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: How do YOU handle scheduling?
I tried basing the class on both the example in the wiki and the example in the book. It works, except the consumer never stops polling when I use the FTP endpoint. I don't know what you are trying to hint at. If I use receive or receiveNoWait does not make any difference. The FTP endpoint keeps on doing LIST on the FTP. -- View this message in context: http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839085.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How do YOU handle scheduling?
The same thing happens in another method I use to enrich a message with a
single specific file:
String ftpsEndpoint =
ftps:{{ftp.address}}{{ftp.path.out}}?delete=trueamp;username={{ftp.username}}password={{ftp.password}}fileName=myFileName
Exchange str = consumer.receive(ftpsEndpoint);
Works fine, except FTP keeps getting polled (nothing gets downloaded) it
just does LIST forever.
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839093.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How do YOU handle scheduling?
You need to stop the consumer because the FTP consumer is schedule
based and will poll using a timer.
So you can stop the consumer template after usage, which should stop
the consumers.
You may also be able to set the cache size of the consumer template to
0 (i dont know if that makes it auto stop the consumer after use, but
I would assume it could do that)
On Tue, Sep 14, 2010 at 3:04 PM, Andreas A. andreasasm...@gmail.com wrote:
The same thing happens in another method I use to enrich a message with a
single specific file:
String ftpsEndpoint =
ftps:{{ftp.address}}{{ftp.path.out}}?delete=trueamp;username={{ftp.username}}password={{ftp.password}}fileName=myFileName
Exchange str = consumer.receive(ftpsEndpoint);
Works fine, except FTP keeps getting polled (nothing gets downloaded) it
just does LIST forever.
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839093.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Multiple Consumers on a Queue
Hi there, We have a FUSE running, and uses a lot of Camel to work on queues etc. Everything works fine, but we have one thing that is quite anoying. Sometimes when we refresh a bundle we suddenly get one more consumer. We can see this with JConsole on the specific Queue. We can do this multiple times a thereby gets a lot of consumers and we can't get rid of them before we shot down the server. I do not know if this is a FUSE og Camel related question - but anyway - hope you can help us out here. Is if possible to kill all consumers on a specific queue? Thanks a lot Roland -- View this message in context: http://camel.465427.n5.nabble.com/Multiple-Consumers-on-a-Queue-tp2839106p2839106.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Problem with protobuf example / Spring DSL to unmarshal to protobuf
Hi, I just checked the schema of camel-spring, it's bug of Camel since Camel 2.3.0, I just logged a JIRA[1] for it and will commit a fix shortly. [1]https://issues.apache.org/activemq/browse/CAMEL-3122 Willem On 9/14/10 5:08 PM, Marcel Jager wrote: Let me describe a step-by-step guide so you can recreate it. Ok, I have constructed a small example using a freshly downloaded copy of Camel 2.4.0. I'am using the provided example protobuffer definition from the example: addressbook.proto and run the protobuffer-compiler protoc to generate the Java-files After that created a spring-xml file in the META-INF/spring directory with the following content: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd; camelContext id=camel xmlns=http://camel.apache.org/schema/spring; route from uri=direct:start/ unmarshal protobuf instanceClass=org.apache.camel.dataformat.protobuf.generated.AddressBookProtos$Person / /unmarshal to uri=mock:result/ /route /camelContext /beans
Re: Multiple Consumers on a Queue
I think that you can connect to activemq through jconsole and kill client connected. Anyway, there is an issue as the JMS Listener is not closed when you stop your bundle. Which version of camel do you use ? On Tue, Sep 14, 2010 at 3:21 PM, Roland Villemoes r...@alpha-solutions.dk wrote: Hi there, We have a FUSE running, and uses a lot of Camel to work on queues etc. Everything works fine, but we have one thing that is quite anoying. Sometimes when we refresh a bundle we suddenly get one more consumer. We can see this with JConsole on the specific Queue. We can do this multiple times a thereby gets a lot of consumers and we can't get rid of them before we shot down the server. I do not know if this is a FUSE og Camel related question - but anyway - hope you can help us out here. Is if possible to kill all consumers on a specific queue? Thanks a lot Roland -- View this message in context: http://camel.465427.n5.nabble.com/Multiple-Consumers-on-a-Queue-tp2839106p2839106.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How do YOU handle scheduling?
Hi
Ok I have corrected my flawed logic to something that works now (I never
reached the consumer.stop() line):
public void poll() throws Exception {
String ftpsUri =
ftp:localhost:1981/inbox?username=camelpassword=camel123move=.done;
String fileUri = file:{{path.out}};
while(true) {
Exchange ex = consumer.receive(ftpsUri, 3000);
if(ex != null) {
producer.send(fileUri, ex);
}
else if (ex == null) {
consumer.stop();
break;
}
}
}
I'm curious as to when you want to use the receiveNoWait method?
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839126.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How do YOU handle scheduling?
On Tue, Sep 14, 2010 at 3:45 PM, Andreas A. andreasasm...@gmail.com wrote:
Hi
Ok I have corrected my flawed logic to something that works now (I never
reached the consumer.stop() line):
public void poll() throws Exception {
String ftpsUri =
ftp:localhost:1981/inbox?username=camelpassword=camel123move=.done;
String fileUri = file:{{path.out}};
while(true) {
Exchange ex = consumer.receive(ftpsUri, 3000);
if(ex != null) {
producer.send(fileUri, ex);
}
else if (ex == null) {
consumer.stop();
break;
}
}
}
I'm curious as to when you want to use the receiveNoWait method?
Maybe when you want to poll a message asap, and NOT wait at all. For
example from a consumer which has an queue of received messages. (eg
SEDA etc.)
--
View this message in context:
http://camel.465427.n5.nabble.com/How-do-YOU-handle-scheduling-tp2838886p2839126.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
[Converter] Generics ?
hello Camel!
Is it possible to use generics in annotated converters ?
I tried to do this
@Converter
public T T toPayload(MessageT msg){
return msg.getPayload();
}
Which does not work. However, replacing T by a real class definition is
working for that type.
I would like to avoid to create one converter for each type of payload my
messages can have, is that possible ?
Thanks in advance,
Olivier
--
View this message in context:
http://camel.465427.n5.nabble.com/Converter-Generics-tp2839250p2839250.html
Sent from the Camel - Users mailing list archive at Nabble.com.
GUI route builder
I imagine such a thing exists, but I can't find one. Is there a GUI tool, or possibly IDE plugin that allows you to visually create routes in Camel?
Re: GUI route builder
On Tue, Sep 14, 2010 at 5:29 PM, Mark Webb elihusma...@gmail.com wrote: I imagine such a thing exists, but I can't find one. Is there a GUI tool, or possibly IDE plugin that allows you to visually create routes in Camel? FuseSource is working on such a tool (current name is Rider). I talked a bit about it in my Camel webinar last week. The webinar will be posted later on the fusesource website. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
example to set priority in message?
I tried to set message priory like below mentioned code. It didn’t work for
me.I am not sure what changes still needed to be done.
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
transacted ref=required /
convertBodyTo type=com.domain.Message /
choice
when
simple${body.entity} is Foo/simple
setHeader
headerName=JMSPriorityconstant1/constant/setHeader
to ref=olapQueue /
/when
when
simple${body.entity} is Bar/simple
setHeader
headerName=JMSPriorityconstant2/constant/setHeader
to ref=oltpQueue /
/when
otherwise
to ref=deadLetterQueue /
/otherwise
/choice
/route
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
resequence
headerJMSPriority/header
to uri=mock:result /
batch-config batchSize=300 batchTimeout=4000 /
/resequence
choice
when
simple${body} is Foo/simple
bean ref=service method=save /
/when
when
simple${body.entity} is Bar/simple
bean ref=userservice method=update /
/when
/choice
transacted ref=required /
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839328.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: example to set priority in message?
What JMS broker are you using? Not all support JMSPriority.
On Tue, Sep 14, 2010 at 5:36 PM, Kannan ramkannan2...@gmail.com wrote:
I tried to set message priory like below mentioned code. It didn’t work for
me.I am not sure what changes still needed to be done.
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
transacted ref=required /
convertBodyTo type=com.domain.Message /
choice
when
simple${body.entity} is Foo/simple
setHeader
headerName=JMSPriorityconstant1/constant/setHeader
to ref=olapQueue /
/when
when
simple${body.entity} is Bar/simple
setHeader
headerName=JMSPriorityconstant2/constant/setHeader
to ref=oltpQueue /
/when
otherwise
to ref=deadLetterQueue /
/otherwise
/choice
/route
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
resequence
headerJMSPriority/header
to uri=mock:result /
batch-config batchSize=300 batchTimeout=4000 /
/resequence
choice
when
simple${body} is Foo/simple
bean ref=service method=save /
/when
when
simple${body.entity} is Bar/simple
bean ref=userservice method=update /
/when
/choice
transacted ref=required /
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839328.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: example to set priority in message?
And you most likely need to set preserveMessageQos=true
http://camel.apache.org/jms
On Tue, Sep 14, 2010 at 5:39 PM, Claus Ibsen claus.ib...@gmail.com wrote:
What JMS broker are you using? Not all support JMSPriority.
On Tue, Sep 14, 2010 at 5:36 PM, Kannan ramkannan2...@gmail.com wrote:
I tried to set message priory like below mentioned code. It didn’t work for
me.I am not sure what changes still needed to be done.
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
transacted ref=required /
convertBodyTo type=com.domain.Message /
choice
when
simple${body.entity} is Foo/simple
setHeader
headerName=JMSPriorityconstant1/constant/setHeader
to ref=olapQueue /
/when
when
simple${body.entity} is Bar/simple
setHeader
headerName=JMSPriorityconstant2/constant/setHeader
to ref=oltpQueue /
/when
otherwise
to ref=deadLetterQueue /
/otherwise
/choice
/route
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
resequence
headerJMSPriority/header
to uri=mock:result /
batch-config batchSize=300 batchTimeout=4000 /
/resequence
choice
when
simple${body} is Foo/simple
bean ref=service method=save /
/when
when
simple${body.entity} is Bar/simple
bean ref=userservice method=update /
/when
/choice
transacted ref=required /
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839328.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: example to set priority in message?
I am using ActiveMQ 5.4.0 -- View this message in context: http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839339.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: example to set priority in message?
A bit info here http://activemq.apache.org/per-destination-policies.html The docu will be improved in the near future On Tue, Sep 14, 2010 at 5:52 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:43 PM, Kannan ramkannan2...@gmail.com wrote: I am using ActiveMQ 5.4.0 You need to enable priority queues in the config somehow. It just been added into AMQ 5.4.0. -- View this message in context: http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839339.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
Re: Camel calling commit too early when using split+seda+file endpoint
Will take a look tomorrow on windows.
On Tue, Sep 14, 2010 at 4:58 PM, camel_el eric.ladouc...@cse-cst.gc.ca wrote:
Claus,
can you try the following piece of code and check if it works or not? (it
doesn't work on my workstation, using camel 2.5.0)
Code
from(file:e:/test)
.split(body().tokenize(,))
.log(Split line ${body})
.process(new Processor()
{
public void process(Exchange e) throws Exception
{ Thread.sleep(2000); } // Simulates long processing happening in my
real application
})
.end()
.log(End of file ${file:name});
Important: make sure you are on Windows and you need at least two input
files in e:\test to see the error. It always happen when camel tries to
move the second file (could be a race condition?)
Let me know.
Thanks
--
View this message in context:
http://camel.465427.n5.nabble.com/Camel-calling-commit-too-early-when-using-split-seda-file-endpoint-tp2830894p2839249.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: example to set priority in message?
I used custom headers instead of JMSPriority to resequence message based on
custom priority header. where as the consumer is not consuming based on
resequence order.
route errorHandlerRef=deadLetterErrorHandler
from ref=queue1 /
resequence
simple${header.msgPriority}simple
to uri=mock:result /
batch-config batchSize=300 batchTimeout=4000 /
/resequence
choice
when
simple${body} is Foo/simple
bean ref=service method=save /
/when
when
simple${body.entity} is Bar/simple
bean ref=userservice method=update /
/when
/choice
transacted ref=required /
/route
--
View this message in context:
http://camel.465427.n5.nabble.com/example-to-set-priority-in-message-tp2839328p2839369.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: GUI route builder
Hi Claus, wasn´t there a GUI for camel in the fuse portfolio since some time? I remember to have seen such a tool that visualized the EAI patterns or was this only experimental? Personally I do not really miss a visual editor for routes. Rather than that I miss a good text based editor that has all the features of the java editor in Eclipse. I always have the problem that I can´t remember the exact syntax of the spring language and the expression languages of camel. An editor with code completion and context sensitive help would really do wonders here. Regards Christian Am 14.09.2010 17:35, schrieb Claus Ibsen: On Tue, Sep 14, 2010 at 5:29 PM, Mark Webbelihusma...@gmail.com wrote: I imagine such a thing exists, but I can't find one. Is there a GUI tool, or possibly IDE plugin that allows you to visually create routes in Camel? FuseSource is working on such a tool (current name is Rider). I talked a bit about it in my Camel webinar last week. The webinar will be posted later on the fusesource website. -- http://www.liquid-reality.de
Re: Odd route start behavior after context is started
Thanks! I'll use the JMS Topic as a temporary workaround until this is fixed. If this doesn't make it in the 2.5 release, I'll try using the DynamicRouter pattern. -- View this message in context: http://camel.465427.n5.nabble.com/Odd-route-start-behavior-after-context-is-started-tp2835464p2839640.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: GUI route builder
Hi Christian, The Fuse tool project abandoned was Fuse Integration Designer. In fact it was an Eclipse version embedding SOA and a Bull project called cimeno. Regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel - Karaf - ServiceMix Committer ~~~ Blog : http://cmoulliard.blogspot.com | Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard On Tue, Sep 14, 2010 at 8:00 PM, Christian Schneider ch...@die-schneider.net wrote: Hi Claus, wasn´t there a GUI for camel in the fuse portfolio since some time? I remember to have seen such a tool that visualized the EAI patterns or was this only experimental? Personally I do not really miss a visual editor for routes. Rather than that I miss a good text based editor that has all the features of the java editor in Eclipse. I always have the problem that I can´t remember the exact syntax of the spring language and the expression languages of camel. An editor with code completion and context sensitive help would really do wonders here. Regards Christian Am 14.09.2010 17:35, schrieb Claus Ibsen: On Tue, Sep 14, 2010 at 5:29 PM, Mark Webbelihusma...@gmail.com wrote: I imagine such a thing exists, but I can't find one. Is there a GUI tool, or possibly IDE plugin that allows you to visually create routes in Camel? FuseSource is working on such a tool (current name is Rider). I talked a bit about it in my Camel webinar last week. The webinar will be posted later on the fusesource website. -- http://www.liquid-reality.de
How to specify route to folder with $ in actual name
We have requirement setup a route to a shared drive on NAS and the folder name on the NAS has name like # Network Location edi.error.report.pdf = \\mltpnfs13\EDI$\dev1\XE.TO.ST\ edi.error.report.txt = \\mltpnfs13\EDI$\dev1\XE.TO.ST\ The bean is reporting errors since it is trying to pick everything after $ as variable. We have tried - \$ - to no luck. Unfortunately - there is no guarantee where the $ sign will be encountered in the folder name - client is using this to hide folders on NAS. Thanks in advance for your help -- View this message in context: http://camel.465427.n5.nabble.com/How-to-specify-route-to-folder-with-in-actual-name-tp2839895p2839895.html Sent from the Camel - Users mailing list archive at Nabble.com.
Camel-QuickFIX - JMX console to invoke quickfix server operations
Hi, I have started Camel-QuickFix component as an acceptor. I have managed to send mock fix messages to the my Camel-Quickfix from FIX Simulator. Now I am trying to turn on JMX support for Camel-QuickFIX component. I went through the QuickFixAcceptor code and have not seen any code that enable JMX support for QuickFix. How can I enable JMX support for Quickfix in Camel so that i could invoke reset, logon, logout and disconnect operations? Kind regards, -Vid- -- View this message in context: http://camel.465427.n5.nabble.com/Camel-QuickFIX-JMX-console-to-invoke-quickfix-server-operations-tp2840088p2840088.html Sent from the Camel - Users mailing list archive at Nabble.com.
camel aggregator differnce between camel 1.6 and came 2.2
Hi, I have been using camel aggregator 1.6 in service 3.3.1. Now servicemix is upgraded to 3.3.2 and they have taken camel 2.2 . There were namespace changes and compilation changes to be done; after this now the xpath filter does not seem to be working as expected Here is the code snippet ( which was working perfectly in 1.6 camel-core) Namespaces ns = new Namespaces(p, http://nsn.com/obs/mw/medfra/snmpbc;); from(jbi:service:http://servicemix.apache.org/test/camel-receiver;) .aggregate(new MyAggregationStrategy()) //camel 2 //.aggregator(new MyAggregationStrategy()) //camel 1.6 signature .xpath(string(/p:snmp-getResponse/p:NE/@ipaddr),String.class, ns) //.completedPredicate(header(completed).isEqualTo(true)) //camel 1.6 .completionPredicate(header(completed).isEqualTo(true)) //camel 2 //.to(jbi:endpoint:http://servicemix.apache.org/test/file_sender_getbulk/endpoint;); // 3 .to(log:tutorial); --- And here is the incoming message ?xml version=1.0 encoding=utf-8? p:snmp-getResponse xmlns:p=http://nsn.com/obs/mw/medfra/snmpbc; xmlns:xsi=http://www.w3.org/2001/XMLSchema; p:NE ipaddr=11.11.12.10 / p:get-response 1.3.6.1.6.3.1.1.4.1.0 p:variable-bindings ... Thanks -- View this message in context: http://camel.465427.n5.nabble.com/camel-aggregator-differnce-between-camel-1-6-and-came-2-2-tp2840127p2840127.html Sent from the Camel - Users mailing list archive at Nabble.com.
