Hello everyone,
It seems that there might be a problem with retrieving the value from
Exchange.REDELIVERY_EXHAUSTED header.
I have a custom defined RedeliveryProcessor which implements Processor and
overrides the public void process(Exchange exchange) method. Within that
method I make a call to:
I also tried
boolean exhausted =
exchange.getIn().getHeader(Exchange.REDELIVERY_EXHAUSTED, Boolean.class);
but that throws a NullPointerException.
--
View this message in context:
http://camel.465427.n5.nabble.com/Unable-to-retrieve-Exchange-REDELIVERY-EXHAUSTED-header-tp3313157p3313158.html
On Mon, Dec 20, 2010 at 11:33 PM, mikaelfj wrote:
>
> Hi,
>
> We are using the bindy component to create fixed length value files, version
> 2.4.
>
> My expectations were, that when defining the length of a field using the
> @DataField annotation, then bindy would pad chars if my data was shorter
The onRedelivery will obvious not be invoked when you are exhausted.
Its only to be invoked *just before* a redelivery attempt is being
made. So that's why the header is absent.
The message do contain information that's its being redelivered. There
is a counter and a boolean headers for that.
You are aware that you do NOT have any MY_ID header when you invoke
the logStart method on the bean, since the message has just been
consumed from a file. Therefore it only contains the CamelFileName
header.
Camel is then not able to map this header.
On Sun, Dec 19, 2010 at 11:00 PM, Craig Taylo
On Tue, Dec 21, 2010 at 10:39 AM, Claus Ibsen wrote:
> You are aware that you do NOT have any MY_ID header when you invoke
> the logStart method on the bean, since the message has just been
> consumed from a file. Therefore it only contains the CamelFileName
> header.
>
> Camel is then not able to
I'll add a jira for it - so far we are ensuring the strings are of proper
length before setting them on the annotated class.
I don't think it should be an option not to clip the string.
If an option is added to control clip/no-clip, you are allowing the
generated fixed-length format to be sort of
Hi
I have an object o that has an enum that I want to change to status
RECEIVED. Is it possible to change this state like o.status =
Status.RECEIVED in the dsl? Or do I have to create a pojo that does this for
me.
--
View this message in context:
http://camel.465427.n5.nabble.com/Change-object-
Hi
You need to use a scripting language such as Groovy, JavaScript or the
likes to be able to execute "code", which you define in the Spring XML
file.
http://camel.apache.org/scripting-languages.html
On Tue, Dec 21, 2010 at 1:05 PM, Andreas A. wrote:
>
> Hi
>
> I have an object o that has an
Hi
Currently the XSD scheme for camel-cxf only has a Spring namespace parser.
We need to add one for OSGi blueprint.
https://issues.apache.org/jira/browse/CAMEL-3452
--
View this message in context:
http://camel.465427.n5.nabble.com/How-to-include-in-a-CXF-Blueprint-Aries-configured-route-tp331
Hi
We have some thoughts of letting camel-jms support using a pluggable
store so it can persist the in flight Exchange. And then on the reply
consumer side, it can peek in the store to find the correlated
Exchange and load it from the store, and continue routing the
Exchange.
Then we can support
Cool; I guess then for this topic I'm missing a review from core committers
(Gert, are you around?), so that I could address feedback. And propose docs
then.
IMO the next logical and handy DSL enhancement would be introduction of
"every(period)", as alias for
"from(timer:someGeneratedName?period=e
Hi all:
Here is what I am experiencing:
After a period of time Camel stops pulling messages off a queue and ActiveMQ
moves them to the DLQ.
Environment:
Camel 2.4.0
Spring 3.0.5
ActiveMQ 5.3.1
My Camel/Spring applications run inside JBoss on linux servers.
The client application uses Produ
Is it timing out?
Have you tried specifying a keep alive parameter to activemq?
val activeMqConnection = "tcp://localhost:61616?keepAlive=true"
-
@tommychheng
http://tommy.chheng.com
On Tue, Dec 21, 2010 at 10:48 AM, Michael La Budde wrote:
>
> Hi all:
>
> Here is what I am experiencing:
>
>
Hi,
Just ran across this one and am not sure if you figured out how to do this.
The Protocol headers in CXF are propagated to Camel exchanges as Camel
Header entries.
The value of AbstractHTTPDestination.HTTP_REQUEST is set to "HTTP.REQUEST"
in the payload and should be found as the same in th
Thanks for the responses Claus and Willem. I couldn't find a JIRA issue
related to jms exchange store, etc. I opened a new JIRA issue for
long-running jms requests:
https://issues.apache.org/jira/browse/CAMEL-3456.
I'm trying to understand the pluggable store you're referring to. I
thin
Regarding the thread pool comment... what is the impact of a
long-running request on thread consumption? If I understand correctly:
- one of the consumer threads will be occupied; so if I configure
"concurrentConsumers=50", then it would consume one of those 50 threads.
- the thread performi
Thanks for the response Ashwin, but I am unable to find the "HTTP.REQUEST"
header in the exchange object.
My process() method is as follows:
public void process (Exchange exchange)
{
Map headers = exchange.getIn().getHeaders();
// loop through the headers object above and print out all
I think on JMS you never can be sure that the consumer is working on a
request. (When using simple request / reply).
So my suggestion is to simply offer a decoupled service that can be
asked about the requests the consumer processes at the moment. I am not
sure if this can be generically suppo
19 matches
Mail list logo
