Re: Hor to route using objects
Hi,
The consumer is a java class and I'm passing a java VO to the producer(s)
depending on certain parameters in the VO.
from(endPoint) // This is a java class and the message is a java object.
.choice()
.when(simple(${body.ID}=='A')).to(serverX)
.when(simple(${body.ID}=='B')).to(serverY)
.otherwise().to(serverZ)
.end();
I wanted to know how I can use a java class as consumer with VO as the
message. Also how the response which will again be a java object can be used
by the consumer.
I understand that camel is designed to work between a wide variety of
components and using from a java class is not really smart thing to do, but
I'm just doin a POC to see what all can be done.
Any insight appretiated.
--
View this message in context:
http://camel.465427.n5.nabble.com/Hor-to-route-using-objects-tp3290076p3290569.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Hor to route using objects
Hi.
You can use camel in your java class like this:
@EndpointInject(uri=direct:start)
protected ProducerTemplate start;
...
start.sendBody(body);
The route should look like this:
from(direct:start) // This is a java class and the message is a java object.
.choice()
.when(simple(${body.ID}=='A')).to(serverX)
.when(simple(${body.ID}=='B')).to(serverY)
.otherwise().to(serverZ)
.end();
For me it's not clear, what do you mean by server? Are the destination
classes are in your context (e.g. spring)? IF yes ist could look like:
from(direct:start) // This is a java class and the message is a java object.
.choice()
.when(simple(${body.ID}=='A')).to(bean:x)
.when(simple(${body.ID}=='B')).to(bean:y)
.otherwise().to(bean:z)
.end();
While x, y, z are the spring ids...
Best regards - Claus
On 03.12.2010 09:59, nkrust wrote:
Hi,
The consumer is a java class and I'm passing a java VO to the producer(s)
depending on certain parameters in the VO.
from(endPoint) // This is a java class and the message is a java object.
.choice()
.when(simple(${body.ID}=='A')).to(serverX)
.when(simple(${body.ID}=='B')).to(serverY)
.otherwise().to(serverZ)
.end();
I wanted to know how I can use a java class as consumer with VO as the
message. Also how the response which will again be a java object can be used
by the consumer.
I understand that camel is designed to work between a wide variety of
components and using from a java class is not really smart thing to do, but
I'm just doin a POC to see what all can be done.
Any insight appretiated.
--
claus straube
__
phone+49-89-38157419
mobile +49-176-49673717
web http://www.catify.com
office 6. floor, heßstr. 56, 80798 munich
__
catify | claus straube, sebastian münz
Propagate exceptions from Camel to wrapping main method?
Hi I have a standalone Camel application: A java main method with a Camel Main class that starts two different contexts. In case of an OutOfMemoryError I would like to propagate this Error from Camel to the enclosing java main method. How can I propagate Errors and Exceptions out of the Camel errorhandling? -- View this message in context: http://camel.465427.n5.nabble.com/Propagate-exceptions-from-Camel-to-wrapping-main-method-tp3290676p3290676.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Thanks Harian Zbarcea: Instrument will be useful. But being wrapped and execute twice for single processor will be a waste; Actually, I found this problem while debug and tracing a spring configured camel route. At least in Camel 2.4.0 and using spring, it real does wrap twice. Maybe you could take a moment to debug and tracking a camel route , you will see it. Or,you can turning on the TRACE level for logging, and checking the Instrument Processor's output. You could see it; Following is my route: route from uri=direct:from / bean id=id0 ref=bean1 method=normal / to id=id0_1 uri=mock:result / bean id=id1 ref=bean1 method=raiseError / /route But the trace result is : 2 of first bean, 2 of the to endpoint, 2 of the second bean and 1 for route; -Origin - Sender: Hadrian Zbarcea [mailto:hzbar...@gmail.com] Date: 2010/12/2 22:21 Receiver: users@camel.apache.org Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor. The InstrumentationProcessor is a delegate processor (aka interceptor) that allows you do do before and after processing. It is not really invoked twice (or I have to see a test case that does that, the unit tests in camel I am aware of don't). It is invoked once, takes a start timestamp, it delegates processing to the inner processor and then takes the time diff and records it. Now with a DelegateProcessor all this call is synchronous. Being actually a DelegateAsyncProcessor, the call to the inner processor is done by the async engine (see AsyncProcessorHelper.process()) which calls asynchronously on the done() method. I assume this is what you see and interpret as a second call. This design is not wasting performance, quite to the contrary. It ensures a better use of resources and scales much better with higher message volume. I hope this helps, Hadrian On Dec 1, 2010, at 9:53 PM, ext2 wrote: Hi: Each camel processor will be wrapped with Instrument Interceptor twice. So for each process , the Instrument interceptor will be executed twice. It seems no use but waste performance; Why? Or a bug? Thanks for any suggestion.
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
Sorry, I forget to attach my tracing result; I am sure , it's wrapped twice; Because the Instrument Processor will trace the time only after processing. But one processor 's instrument result is traced twice; Following is my tracing output, you can check it. - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain text] - to: Recording duration: 11 millis for exchange: Exchange[Message: plain text] - to: Recording duration: 18 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain text] - route: Recording duration: 160 millis for exchange: Exchange[Message: plain text] -Original - Sender: ext2 [mailto:x...@tongtech.com] Date: 2010-12-3 19:23 Receiver: users@camel.apache.org Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor. Thanks Harian Zbarcea: Instrument will be useful. But being wrapped and execute twice for single processor will be a waste; Actually, I found this problem while debug and tracing a spring configured camel route. At least in Camel 2.4.0 and using spring, it real does wrap twice. Maybe you could take a moment to debug and tracking a camel route , you will see it. Or,you can turning on the TRACE level for logging, and checking the Instrument Processor's output. You could see it; Following is my route: route from uri=direct:from / bean id=id0 ref=bean1 method=normal / to id=id0_1 uri=mock:result / bean id=id1 ref=bean1 method=raiseError / /route But the trace result is : 2 of first bean, 2 of the to endpoint, 2 of the second bean and 1 for route; -Origin - Sender: Hadrian Zbarcea [mailto:hzbar...@gmail.com] Date: 2010/12/2 22:21 Receiver: users@camel.apache.org Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor. The InstrumentationProcessor is a delegate processor (aka interceptor) that allows you do do before and after processing. It is not really invoked twice (or I have to see a test case that does that, the unit tests in camel I am aware of don't). It is invoked once, takes a start timestamp, it delegates processing to the inner processor and then takes the time diff and records it. Now with a DelegateProcessor all this call is synchronous. Being actually a DelegateAsyncProcessor, the call to the inner processor is done by the async engine (see AsyncProcessorHelper.process()) which calls asynchronously on the done() method. I assume this is what you see and interpret as a second call. This design is not wasting performance, quite to the contrary. It ensures a better use of resources and scales much better with higher message volume. I hope this helps, Hadrian On Dec 1, 2010, at 9:53 PM, ext2 wrote: Hi: Each camel processor will be wrapped with Instrument Interceptor twice. So for each process , the Instrument interceptor will be executed twice. It seems no use but waste performance; Why? Or a bug? Thanks for any suggestion.
Re: Wast performance? Instrument Interceptor is wrapped twice for each processor.
On Fri, Dec 3, 2010 at 2:24 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: I did look at few examples. In your case, from looking at the log, it looks like it's wrapped twice, that's why is executed twice. The second number is always larger than the first. Since the Trace is an interceptor too, it looks like you got an instrument(trace(instrument(processor))). I will take a look today and see where the problem lies. In any event, your assumption is correct, instrumentation should not happen twice, and if does it is a bug. Thanks for pointing this out, Hadrian We'll revisit this in Camel 3.0 where the idea is to make the interception/wrapper dynamic and decided at runtime, instead of laid out at route initialization time. The logic deciding to do this would then be easier to implement. On Dec 3, 2010, at 7:15 AM, ext2 wrote: Sorry, I forget to attach my tracing result; I am sure , it's wrapped twice; Because the Instrument Processor will trace the time only after processing. But one processor 's instrument result is traced twice; Following is my tracing output, you can check it. - bean: Recording duration: 23 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 52 millis for exchange: Exchange[Message: plain text] - to: Recording duration: 11 millis for exchange: Exchange[Message: plain text] - to: Recording duration: 18 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 11 millis for exchange: Exchange[Message: plain text] - bean: Recording duration: 48 millis for exchange: Exchange[Message: plain text] - route: Recording duration: 160 millis for exchange: Exchange[Message: plain text] -Original - Sender: ext2 [mailto:x...@tongtech.com] Date: 2010-12-3 19:23 Receiver: users@camel.apache.org Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor. Thanks Harian Zbarcea: Instrument will be useful. But being wrapped and execute twice for single processor will be a waste; Actually, I found this problem while debug and tracing a spring configured camel route. At least in Camel 2.4.0 and using spring, it real does wrap twice. Maybe you could take a moment to debug and tracking a camel route , you will see it. Or,you can turning on the TRACE level for logging, and checking the Instrument Processor's output. You could see it; Following is my route: route from uri=direct:from / bean id=id0 ref=bean1 method=normal / to id=id0_1 uri=mock:result / bean id=id1 ref=bean1 method=raiseError / /route But the trace result is : 2 of first bean, 2 of the to endpoint, 2 of the second bean and 1 for route; -Origin - Sender: Hadrian Zbarcea [mailto:hzbar...@gmail.com] Date: 2010/12/2 22:21 Receiver: users@camel.apache.org Subject: Re: Wast performance? Instrument Interceptor is wrapped twice for each processor. The InstrumentationProcessor is a delegate processor (aka interceptor) that allows you do do before and after processing. It is not really invoked twice (or I have to see a test case that does that, the unit tests in camel I am aware of don't). It is invoked once, takes a start timestamp, it delegates processing to the inner processor and then takes the time diff and records it. Now with a DelegateProcessor all this call is synchronous. Being actually a DelegateAsyncProcessor, the call to the inner processor is done by the async engine (see AsyncProcessorHelper.process()) which calls asynchronously on the done() method. I assume this is what you see and interpret as a second call. This design is not wasting performance, quite to the contrary. It ensures a better use of resources and scales much better with higher message volume. I hope this helps, Hadrian On Dec 1, 2010, at 9:53 PM, ext2 wrote: Hi: Each camel processor will be wrapped with Instrument Interceptor twice. So for each process , the Instrument interceptor will be executed twice. It seems no use but waste performance; Why? Or a bug? Thanks for any suggestion. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
[Serialization] CamelAuthentication is null
Hello Camel, I get this error in the log when I try to serialize my Exchanges with the DefaultExchangeHandler: DefaultExchangeHolder| camel.impl.DefaultExchangeHolder 210 | 69 - org.apache.camel.camel-core - 2.4.0.fuse-00-00 | in headers containing object: null with key: CamelAuthentication cannot be serialized, it will be excluded by the holder. Is this normal that CamelAuthentication is present but null in the exchange headers ? -- View this message in context: http://camel.465427.n5.nabble.com/Serialization-CamelAuthentication-is-null-tp3290948p3290948.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Serialization] CamelAuthentication is null
It is not normal, and reviewing the Camel code (2.6-SNAPSHOT, not the 2.4.0.fuse-00-00 you're using), I don't see where this could have happened. What do you use for authentication, spring-security? Is there a test case? Thanks Hadrian On Dec 3, 2010, at 9:23 AM, Olivier.Roger wrote: Hello Camel, I get this error in the log when I try to serialize my Exchanges with the DefaultExchangeHandler: DefaultExchangeHolder| camel.impl.DefaultExchangeHolder 210 | 69 - org.apache.camel.camel-core - 2.4.0.fuse-00-00 | in headers containing object: null with key: CamelAuthentication cannot be serialized, it will be excluded by the holder. Is this normal that CamelAuthentication is present but null in the exchange headers ? -- View this message in context: http://camel.465427.n5.nabble.com/Serialization-CamelAuthentication-is-null-tp3290948p3290948.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Serialization] CamelAuthentication is null
Yes this is a test case. I did not set any authentication, that is why I am surprised there is a CamelAuthentication header present in the exchange. I will trace the exchanges to locate more precisely where the header appears and get back to you. Thanks for your help -- View this message in context: http://camel.465427.n5.nabble.com/Serialization-CamelAuthentication-is-null-tp3290948p3290979.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: [Serialization] CamelAuthentication is null
Can you post the route? I think the header should not be set if the value is null. Likewise the exchange holder should not warn if the value is null, but just silently ignores it. On Fri, Dec 3, 2010 at 3:48 PM, Olivier.Roger olivier.ro...@bsb.com wrote: Yes this is a test case. I did not set any authentication, that is why I am surprised there is a CamelAuthentication header present in the exchange. I will trace the exchanges to locate more precisely where the header appears and get back to you. Thanks for your help -- View this message in context: http://camel.465427.n5.nabble.com/Serialization-CamelAuthentication-is-null-tp3290948p3290979.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
