RE: How to remove interceptors?
Thanks both, very helpful answers! BR, Marcos. View this message in context: http://camel.465427.n5.nabble.com/How-to-remove-interceptors-tp4431339p4432115.html Sent from the Camel - Users mailing list archive at Nabble.com.
Camel AWS component
Guys, I don't know is it will be useful for anybody but I did a little update for camel AWS component here https://github.com/abashev/camel-aws/commits/master Changes: - Components for SNS and SQS are working with 2.7.1 version - Add integration with Simple Email service (CAMEL-3591) - Add processing File objects for S3 (really useful with big files and streams) Any comments are welcome, Thank you. -- View this message in context: http://camel.465427.n5.nabble.com/Camel-AWS-component-tp4438690p4438690.html Sent from the Camel - Users mailing list archive at Nabble.com.
Unit test camel with activeMQ
Hello,
I used Junit for java program but I need some examples to understand how it
works in camel with activeMQ
I wrote a simple camel.xml as follow :
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=activemq:start/
bean ref=MyBean method=route /
to uri=activemq:finish/
/route
/camelContext
and MyBean.java is :
public class MyBean {
public void route(Exchange message){
String name = message.getIn().getBody(String.class);
name=test;
message.getOut().setBody(name);
}
}
In my route I send any string like my unit Test, this string received by
the bean and affecte test in my String and route it to activemq:finish.
How can I write a unit test for that simple code ?
In my test I was wondring if my activemq must be started ?
I will appreciate your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-camel-with-activeMQ-tp4438797p4438797.html
Sent from the Camel - Users mailing list archive at Nabble.com.
AW: Unit test camel with activeMQ
First thing. You can very nicely test such routes. Camel provides some nice
test classes and also the great mock:endpoint.
It would be a bit lengthy to describe how to do it in the mail. I think you
best look into the tests of the jms component. They test very similar things.
https://svn.apache.org/repos/asf/camel/trunk/components/camel-jms/src/test/
Christian
-Ursprüngliche Nachricht-
Von: hbellat [mailto:hbel...@gmail.com]
Gesendet: Montag, 30. Mai 2011 11:19
An: users@camel.apache.org
Betreff: Unit test camel with activeMQ
Hello,
I used Junit for java program but I need some examples to understand how it
works in camel with activeMQ
I wrote a simple camel.xml as follow :
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=activemq:start/
bean ref=MyBean method=route /
to uri=activemq:finish/
/route
/camelContext
and MyBean.java is :
public class MyBean {
public void route(Exchange message){
String name = message.getIn().getBody(String.class);
name=test;
message.getOut().setBody(name);
}
}
In my route I send any string like my unit Test, this string received by the
bean and affecte test in my String and route it to activemq:finish.
How can I write a unit test for that simple code ?
In my test I was wondring if my activemq must be started ?
I will appreciate your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-camel-with-activeMQ-tp4438797p4438797.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: @XPath for an Integer
NaN goes for any Number object. 2011/5/26 Claus Ibsen claus.ib...@gmail.com On Thu, May 26, 2011 at 5:44 PM, boday ben.o...@initekconsulting.com wrote: agreed...I'll update the patch. While we are at it, are there any other cases that should be addressed? I wonder if BigDecimal has any similar NaN stuff? bvahdat wrote: I think that not only Double.NaN should be catched but also Float.NaN. - Ben O'Day IT Consultant -http://benoday.blogspot.com -- View this message in context: http://camel.465427.n5.nabble.com/XPath-for-an-Integer-tp4422095p4429030.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com CamelOne 2011: http://fusesource.com/camelone2011/ Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- -- David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: Issue unmarshalling Fixed Length message date
On Sun, May 29, 2011 at 11:46 PM, Christian Müller
christian.muel...@gmail.com wrote:
The problem was the wrong pos parameter in the @DataField annotation. We
cannot use pos=1, pos=2, pos=3 and so on, if the fields are longer than only
one character.
Weird. Can you highlight this, eg the problem?
I would expect the pos attribute to be mandatory and unique, to
indicate the order of the fields.
Christian
On Sun, May 29, 2011 at 2:27 PM, Claus Ibsen claus.ib...@gmail.com wrote:
On Sun, May 29, 2011 at 1:00 PM, Christian Müller
christian.muel...@gmail.com wrote:
The problem are the wrong bean annotations. The unit test [1] should be
helpful for you. May be we can make Camel a bit smarter.
Your correct bean annotations should look like the following:
@FixedLengthRecord(length=71, paddingChar=' ')
public class FixedLengthBean implements Serializable {
@DataField(pos=1, length=15, pattern=000)
private long field1;
@DataField(pos=16, length=10, pattern=00, required=true)
private long field2;
@DataField(pos=26, length=10, pattern=00, required=true)
private long field3;
@DataField(pos=36, length=1, required=true)
private char field4;
@DataField(pos=37, length=10)
private String field5;
@DataField(pos=47, length=12, required=true)
private String field6;
@DataField(pos=59, length=1, required=true)
private char field7;
@DataField(pos=60, length=2)
private String field8;
@DataField(pos=62, length=8, pattern=MMdd)
private Date field9;
@DataField(pos=70, length=2)
private String field10;
}
With this configuration my unit test passed all tests.
Ah so for the long/int fields we have to set pattern= ?
If so yeah that should be enhanced/fixed.
Can you create a ticket?
[1]
https://svn.apache.org/repos/asf/camel/trunk/components/camel-bindy/src/test/java/org/apache/camel/dataformat/bindy/fixed/unmarshall/simple/trim/BindySimpleFixedLengthUnmarshallTest.java
Best,
Christian
On Fri, May 27, 2011 at 1:37 PM, Claus Ibsen claus.ib...@gmail.com
wrote:
Hi
Yeah it seems odd why the field at position 9 is not grabbing further
into the text, where the date is.
Fell free to create a JIRA ticket and attach an unit test showing the
problem. Then we can use that to fix the bug.
On Fri, May 27, 2011 at 11:41 AM, cconesa
carlos.con...@rulefinancial.com wrote:
p
This is my route configuration for test. I think I am using the rigth
bindy..
/p
code
@Configuration
public static class ContextConfig extends
SingleRouteCamelConfiguration {
BindyFixedLengthDataFormat camelDataFormat = new
BindyFixedLengthDataFormat(
org.mypckg.dataformat.fixedlength.model);
@Override
@Bean
public RouteBuilder route() {
return new RouteBuilder() {
@Override
public void configure() {
from(direct:start).marshal(camelDataFormat).to(
mock:result);
}
};
}
}
/code
--
View this message in context:
http://camel.465427.n5.nabble.com/Issue-unmarshalling-Fixed-Length-message-date-tp4431276p4431347.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Unit test camel with activeMQ
Hi,
It depends on if you want to start the JMS broker.
In most case, you don't need to start the JMS broker if you just want to
test the route method.
So you can replace the activemq to direct or seda endpoint.
There are some useful discussion in the Chapter6 of Camel in Action.
On 5/30/11 5:19 PM, hbellat wrote:
Hello,
I used Junit for java program but I need some examples to understand how it
works in camel with activeMQ
I wrote a simple camel.xml as follow :
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=activemq:start/
bean ref=MyBean method=route /
to uri=activemq:finish/
/route
/camelContext
and MyBean.java is :
public class MyBean {
public void route(Exchange message){
String name = message.getIn().getBody(String.class);
name=test;
message.getOut().setBody(name);
}
}
In my route I send any string like my unit Test, this string received by
the bean and affecte test in my String and route it to activemq:finish.
How can I write a unit test for that simple code ?
In my test I was wondring if my activemq must be started ?
I will appreciate your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-camel-with-activeMQ-tp4438797p4438797.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog:http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
AW: Symmetric routes
Hi, one important thing to take into consideration is the asynchronous nature of FIX messaging. I am not sure how an InOut exchange would enable that. A typical interaction would be as such: order request order ack partial execution ... completed execution So this would be something like an in exchange followed by several out exchanges - if there is such a thing. Another aspect to consider is the bidirectional nature of the pipeline, i.e. the message needs transformation in both directions. Could these requirements be met by adding in-out capability to the quickfixj Component? Cheers, Beat; -Ursprüngliche Nachricht- Von: Ashwin Karpe [mailto:aka...@fusesource.com] Gesendet: Freitag, 27. Mai 2011 15:53 An: users@camel.apache.org Betreff: Re: Symmetric routes Hi, I did a little digging and it turns out that the QuickfixJ Converter creates an in-only exchange... Not sure why, but then again I am not very conversant with Quickfix and the message exchange patterns it supports. If the exchange can be made to be an in-out exchange and the the Quickfix event listener can also send responses to the endpoint, then you will not need to write the second route. Camel is fully capable of sending back responses (as we do in CXF) when using in-out exchanges. The camel-quickfix component does not support this. If you would like to have this capability and it is a valid usecase per quickfix message exchange patterns, I would be happen to add a Jira issue for the same. Can you please let men know. Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com Blog: http://opensourceknowledge.blogspot.com CamelOne 2011: http://fusesource.com/camel2011 - -- View this message in context: http://camel.465427.n5.nabble.com/Symmetric-routes-tp4431615p4432079.html Sent from the Camel - Users mailing list archive at Nabble.com. Bitte oeffnen Sie nicht jedes Mail-/Attachement. Achten Sie auf den Absender und beachten Sie die Sprache in der das Mail erstellt wurde. Sollten Sie z.B. ein Mail erhalten von einem Absender der normalerweise Mails in Deutsch verfasst, dann seien Sie doppelt vorsichtig wenn es Englisch ist. Diese Nachricht ist ausschliesslich für den obgenannten Empfaenger bestimmt. Sollten Sie diese Nachricht irrtuemlich erhalten haben, benachrichtigen Sie uns bitte und zerstoeren Sie diese sofort ohne in irgendeiner Weise davon Gebrauch zu machen. Da elektronische Kommunikation ohne Ihr oder unser Wissen eingesehen, gefaelscht oder veraendert werden kann, lehnen wir jede Verantwortung für die Geheimhaltung und Unversehrtheit dieser Nachricht ab. This message is confidential and only for the use of the above named recipient. Should you have received this message in error, please contact us and destroy it immediately without using it in any way. Since electronic communication can be viewed, forged, or altered without your or our knowledge, we decline any responsibility for the confidentiality or unaltered content of this message.
Re: AW: Symmetric routes
Glattfelder, I think that in some cases it would make sense to support the InOut MEP for FIX. Certain pairs of FIX message types are logically a request-reply pair. Order execution is not in that category because of the multiple asynchrnous replies, but a FIX OrderStatusRequest could potentially be represented as an InOut exchange. On the consumer side, the message would be processed by a synchronous service (like a status reporting service) and the response would be sent back to the requesting FIX session. On the producer side, an InOut message exchange could be supported for FIX messages that represent request-reply interactions. The behavior would be similar to using request-reply with JMS. However, it's a little more complicated in FIX because the correlation key differs between message pairs and versions of the FIX specification. I've modified the Quickfix component (locally) to optionally support InOut for consumers and producers. I created a consumer example that routes InOut status request messages to a synchronous status reporting service. I've also created a producer example that receives status requests from a jetty web component. The web service request is transformed and then routed as an InOut exchange to a quickfix endpoint. The quickfix reply FIX message is then transformed to JSON and routed back to the jetty component which returns it to the web service client. Although this doesn't remove the duplication in the example you provided, it might be useful in other situations. Regards, Steve On 5/30/11 6:22 AM, Glattfelder Beat beat.glattfel...@incorebank.ch wrote: Hi, one important thing to take into consideration is the asynchronous nature of FIX messaging. I am not sure how an InOut exchange would enable that. A typical interaction would be as such: order request order ack partial execution ... completed execution So this would be something like an in exchange followed by several out exchanges - if there is such a thing. Another aspect to consider is the bidirectional nature of the pipeline, i.e. the message needs transformation in both directions. Could these requirements be met by adding in-out capability to the quickfixj Component? Cheers, Beat; -Ursprüngliche Nachricht- Von: Ashwin Karpe [mailto:aka...@fusesource.com] Gesendet: Freitag, 27. Mai 2011 15:53 An: users@camel.apache.org Betreff: Re: Symmetric routes Hi, I did a little digging and it turns out that the QuickfixJ Converter creates an in-only exchange... Not sure why, but then again I am not very conversant with Quickfix and the message exchange patterns it supports. If the exchange can be made to be an in-out exchange and the the Quickfix event listener can also send responses to the endpoint, then you will not need to write the second route. Camel is fully capable of sending back responses (as we do in CXF) when using in-out exchanges. The camel-quickfix component does not support this. If you would like to have this capability and it is a valid usecase per quickfix message exchange patterns, I would be happen to add a Jira issue for the same. Can you please let men know. Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com Blog: http://opensourceknowledge.blogspot.com CamelOne 2011: http://fusesource.com/camel2011 -
error in interceptor: InputStreamCache cannot be cast to org.w3c.dom.Node
Hello all, I am implementing a monitor on my routes, using an interceptor. I am using Camel 2.3.0 inside Servicemix 3.3.2. The routes are working ok without the interceptor. In the monitor, I try to log the message, but it seems (not sure about this, just a guess) that that is causing the InputStream to be read and then It seems that it can not be read again. I am already using getContext().setStreamCaching(true); in my routes. Below, you can see the stack trace, any comments or help on this will be welcome. Thank you in advance. Javier Arias. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. 20110530-12:58:52.213 | ERROR | DefaultMessageListenerContainer-1 | he.camel.processor.Logger 248 | Failed delivery for exchangeId: ID:COMMSPRE-39182-1306750664774-2:48:1:1:1. Exhausted after delivery attempt: 5 caught: java.lang.ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node. Processed by failure processor: sendTo(Endpoint[activemq://deadletterq.activationrequest]) java.lang.ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:116) at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:98) at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:180) at org.apache.camel.builder.xml.XPathBuilder.doInEvaluateAs(XPathBuilder.java:492) at org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:464) at org.apache.camel.builder.xml.XPathBuilder.matches(XPathBuilder.java:121) at org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:48) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcessor.java:53) at org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.java:82) at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:93) at com.monitor.MonitorXceptorProcessor.process(MonitorXceptorProcessor.java:59) at org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.RedeliveryErrorHandler.processExchange(RedeliveryErrorHandler.java:177) at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:143) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:88) at org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:56) at org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:231) at org.apache.camel.processor.Pipeline.process(Pipeline.java:74) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcessor.java:53) at org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.java:82) at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:93) at com.monitor.MonitorXceptorProcessor.process(MonitorXceptorProcessor.java:59) at org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.RedeliveryErrorHandler.processExchange(RedeliveryErrorHandler.java:177) at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:143) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:88) at org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:56) at org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:231) at org.apache.camel.processor.UnitOfWorkProcessor.processNext(UnitOfWorkProcessor.java:66) at org.apache.camel.processor.DelegateProcessor.process(DelegateProcessor.java:48) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:84) at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:543) at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:482
Re: error in interceptor: InputStreamCache cannot be cast to org.w3c.dom.Node
In your custom interceptor, then you can either - skip any streams (eg do not touch them) - reset the stream cache By resetting the stream cache you should be able to re-read the stram again. There is some code on trunk that does that. On Mon, May 30, 2011 at 1:37 PM, Javier Arias Losada javier.ari...@gmail.com wrote: Hello all, I am implementing a monitor on my routes, using an interceptor. I am using Camel 2.3.0 inside Servicemix 3.3.2. The routes are working ok without the interceptor. In the monitor, I try to log the message, but it seems (not sure about this, just a guess) that that is causing the InputStream to be read and then It seems that it can not be read again. I am already using getContext().setStreamCaching(true); in my routes. Below, you can see the stack trace, any comments or help on this will be welcome. Thank you in advance. Javier Arias. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. [Fatal Error] :-1:-1: Premature end of file. 20110530-12:58:52.213 | ERROR | DefaultMessageListenerContainer-1 | he.camel.processor.Logger 248 | Failed delivery for exchangeId: ID:COMMSPRE-39182-1306750664774-2:48:1:1:1. Exhausted after delivery attempt: 5 caught: java.lang.ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node. Processed by failure processor: sendTo(Endpoint[activemq://deadletterq.activationrequest]) java.lang.ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:116) at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:98) at com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:180) at org.apache.camel.builder.xml.XPathBuilder.doInEvaluateAs(XPathBuilder.java:492) at org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:464) at org.apache.camel.builder.xml.XPathBuilder.matches(XPathBuilder.java:121) at org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:48) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcessor.java:53) at org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.java:82) at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:93) at com.monitor.MonitorXceptorProcessor.process(MonitorXceptorProcessor.java:59) at org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.RedeliveryErrorHandler.processExchange(RedeliveryErrorHandler.java:177) at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:143) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:88) at org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:56) at org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:231) at org.apache.camel.processor.Pipeline.process(Pipeline.java:74) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.DelegateProcessor.processNext(DelegateProcessor.java:53) at org.apache.camel.processor.DelegateProcessor.proceed(DelegateProcessor.java:82) at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:93) at com.monitor.MonitorXceptorProcessor.process(MonitorXceptorProcessor.java:59) at org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52) at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:67) at org.apache.camel.processor.RedeliveryErrorHandler.processExchange(RedeliveryErrorHandler.java:177) at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:143) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:88) at org.apache.camel.processor.DeadLetterChannel.process(DeadLetterChannel.java:56) at org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:231) at org.apache.camel.processor.UnitOfWorkProcessor.processNext(UnitOfWorkProcessor.java:66) at org.apache.camel.processor.DelegateProcessor.process(DelegateProcessor.java:48) at org.apache.camel.management.InstrumentationProcessor.process
Re: Unit test camel with activeMQ
On Mon, May 30, 2011 at 12:04 PM, Willem Jiang willem.ji...@gmail.com wrote:
Hi,
It depends on if you want to start the JMS broker.
In most case, you don't need to start the JMS broker if you just want to
test the route method.
Yeah the camel-activemq component can automatic embed a local broker.
Thats very convenient for unit testing.
And you can use the vm protocol so you do not send messages over TCP
and whatnot.
As mentioned the unit tests of camel-jms shows that. Likewise some of
the examples using JMS.
And in terms of the Camel book, then chapter 7 covers using JMS and
have source code with unit tests as well.
So you can replace the activemq to direct or seda endpoint.
There are some useful discussion in the Chapter6 of Camel in Action.
On 5/30/11 5:19 PM, hbellat wrote:
Hello,
I used Junit for java program but I need some examples to understand how
it
works in camel with activeMQ
I wrote a simple camel.xml as follow :
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=activemq:start/
bean ref=MyBean method=route /
to uri=activemq:finish/
/route
/camelContext
and MyBean.java is :
public class MyBean {
public void route(Exchange message){
String name = message.getIn().getBody(String.class);
name=test;
message.getOut().setBody(name);
}
}
In my route I send any string like my unit Test, this string received by
the bean and affecte test in my String and route it to activemq:finish.
How can I write a unit test for that simple code ?
In my test I was wondring if my activemq must be started ?
I will appreciate your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-camel-with-activeMQ-tp4438797p4438797.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Willem
--
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
--
Claus Ibsen
-
FuseSource
Email: cib...@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Problems triggering a camel route in OSGi
I have a very strange problem that is probably related to classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger method looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer = mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In real life,
the direct:start route is meant to be triggered via a published OSGi
service (actually through a web service call). However, this does not work
at all.
Whenever I try to call the trigger() method from somewhere else, the
mCamelContext member is null and I get a NPE when trying to create the
producer template. Why is that?
I realize that this might not be a Camel problem but a OSGi/iPOJO problem
but it's definitely related to Camel. I checked what class loader is being
used to for the mCamelContext instance and it turns out to be the
camel-spring bundle's class loader. Could that be related to my problems?
I am very confused about this and would appreciate any help,
/Bengt
AW: AW: Symmetric routes
Steve, I absolutely agree on your findings, I have been thinking about this as well and figured that since you have to set up message / event driven processing anyway, the additional complexity in correlating some messages to enable a request reply paradigm would not be justified. What I actually am looking for, is a possibility to reference endpoints in camel-spring routes. In Java on can instantiate an endpoint and then use it in the from clause - is there a way to do this in spring routes? Cheers, Beat PS: please call me Beat, in the old world we sometimes place the family name first in addresses ;) -Ursprüngliche Nachricht- Von: Stephen Bate [mailto:b...@technoetic.com] Gesendet: Montag, 30. Mai 2011 13:24 An: users@camel.apache.org Betreff: Re: AW: Symmetric routes Glattfelder, I think that in some cases it would make sense to support the InOut MEP for FIX. Certain pairs of FIX message types are logically a request-reply pair. Order execution is not in that category because of the multiple asynchrnous replies, but a FIX OrderStatusRequest could potentially be represented as an InOut exchange. On the consumer side, the message would be processed by a synchronous service (like a status reporting service) and the response would be sent back to the requesting FIX session. On the producer side, an InOut message exchange could be supported for FIX messages that represent request-reply interactions. The behavior would be similar to using request-reply with JMS. However, it's a little more complicated in FIX because the correlation key differs between message pairs and versions of the FIX specification. I've modified the Quickfix component (locally) to optionally support InOut for consumers and producers. I created a consumer example that routes InOut status request messages to a synchronous status reporting service. I've also created a producer example that receives status requests from a jetty web component. The web service request is transformed and then routed as an InOut exchange to a quickfix endpoint. The quickfix reply FIX message is then transformed to JSON and routed back to the jetty component which returns it to the web service client. Although this doesn't remove the duplication in the example you provided, it might be useful in other situations. Regards, Steve On 5/30/11 6:22 AM, Glattfelder Beat beat.glattfel...@incorebank.ch wrote: Hi, one important thing to take into consideration is the asynchronous nature of FIX messaging. I am not sure how an InOut exchange would enable that. A typical interaction would be as such: order request order ack partial execution ... completed execution So this would be something like an in exchange followed by several out exchanges - if there is such a thing. Another aspect to consider is the bidirectional nature of the pipeline, i.e. the message needs transformation in both directions. Could these requirements be met by adding in-out capability to the quickfixj Component? Cheers, Beat; -Ursprüngliche Nachricht- Von: Ashwin Karpe [mailto:aka...@fusesource.com] Gesendet: Freitag, 27. Mai 2011 15:53 An: users@camel.apache.org Betreff: Re: Symmetric routes Hi, I did a little digging and it turns out that the QuickfixJ Converter creates an in-only exchange... Not sure why, but then again I am not very conversant with Quickfix and the message exchange patterns it supports. If the exchange can be made to be an in-out exchange and the the Quickfix event listener can also send responses to the endpoint, then you will not need to write the second route. Camel is fully capable of sending back responses (as we do in CXF) when using in-out exchanges. The camel-quickfix component does not support this. If you would like to have this capability and it is a valid usecase per quickfix message exchange patterns, I would be happen to add a Jira issue for the same. Can you please let men know. Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com Blog: http://opensourceknowledge.blogspot.com CamelOne 2011: http://fusesource.com/camel2011 - Bitte oeffnen Sie nicht jedes Mail-/Attachement. Achten Sie auf den Absender und beachten Sie die Sprache in der das Mail erstellt wurde. Sollten Sie z.B. ein Mail erhalten von einem Absender der normalerweise Mails in Deutsch verfasst, dann seien Sie doppelt vorsichtig wenn es Englisch ist. Diese Nachricht ist ausschliesslich für den obgenannten Empfaenger bestimmt. Sollten Sie diese Nachricht irrtuemlich erhalten haben, benachrichtigen Sie uns bitte und zerstoeren Sie diese sofort ohne in irgendeiner Weise davon Gebrauch zu machen. Da elektronische Kommunikation ohne Ihr
Re: Problems triggering a camel route in OSGi
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also
exposed as webservice, and in this webservice impl class you invoke
trigger method?
Or your camel router bundle also published as a OSGi service, from
which other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to
classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created
like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger
method looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer =
mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In
real life,
the direct:start route is meant to be triggered via a published
OSGi
service (actually through a web service call). However, this does
not work
at all.
Whenever I try to call the trigger() method from somewhere else, the
mCamelContext member is null and I get a NPE when trying to create the
producer template. Why is that?
I realize that this might not be a Camel problem but a OSGi/iPOJO
problem
but it's definitely related to Camel. I checked what class loader is
being
used to for the mCamelContext instance and it turns out to be the
camel-spring bundle's class loader. Could that be related to my
problems?
I am very confused about this and would appreciate any help,
/Bengt
-
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
Re: AW: Symmetric routes
On Mon, May 30, 2011 at 3:09 PM, Glattfelder Beat beat.glattfel...@incorebank.ch wrote: Steve, I absolutely agree on your findings, I have been thinking about this as well and figured that since you have to set up message / event driven processing anyway, the additional complexity in correlating some messages to enable a request reply paradigm would not be justified. What I actually am looking for, is a possibility to reference endpoints in camel-spring routes. In Java on can instantiate an endpoint and then use it in the from clause - is there a way to do this in spring routes? Sure something like this: endpoint id=myEndpoint uri=blah/ route from ref=myEndpoint/ ... The ref will lookup an id in the spring registry, so you can also use a spring bean style if you like bean id=myEndpoint class= ... /bean Cheers, Beat PS: please call me Beat, in the old world we sometimes place the family name first in addresses ;) -Ursprüngliche Nachricht- Von: Stephen Bate [mailto:b...@technoetic.com] Gesendet: Montag, 30. Mai 2011 13:24 An: users@camel.apache.org Betreff: Re: AW: Symmetric routes Glattfelder, I think that in some cases it would make sense to support the InOut MEP for FIX. Certain pairs of FIX message types are logically a request-reply pair. Order execution is not in that category because of the multiple asynchrnous replies, but a FIX OrderStatusRequest could potentially be represented as an InOut exchange. On the consumer side, the message would be processed by a synchronous service (like a status reporting service) and the response would be sent back to the requesting FIX session. On the producer side, an InOut message exchange could be supported for FIX messages that represent request-reply interactions. The behavior would be similar to using request-reply with JMS. However, it's a little more complicated in FIX because the correlation key differs between message pairs and versions of the FIX specification. I've modified the Quickfix component (locally) to optionally support InOut for consumers and producers. I created a consumer example that routes InOut status request messages to a synchronous status reporting service. I've also created a producer example that receives status requests from a jetty web component. The web service request is transformed and then routed as an InOut exchange to a quickfix endpoint. The quickfix reply FIX message is then transformed to JSON and routed back to the jetty component which returns it to the web service client. Although this doesn't remove the duplication in the example you provided, it might be useful in other situations. Regards, Steve On 5/30/11 6:22 AM, Glattfelder Beat beat.glattfel...@incorebank.ch wrote: Hi, one important thing to take into consideration is the asynchronous nature of FIX messaging. I am not sure how an InOut exchange would enable that. A typical interaction would be as such: order request order ack partial execution ... completed execution So this would be something like an in exchange followed by several out exchanges - if there is such a thing. Another aspect to consider is the bidirectional nature of the pipeline, i.e. the message needs transformation in both directions. Could these requirements be met by adding in-out capability to the quickfixj Component? Cheers, Beat; -Ursprüngliche Nachricht- Von: Ashwin Karpe [mailto:aka...@fusesource.com] Gesendet: Freitag, 27. Mai 2011 15:53 An: users@camel.apache.org Betreff: Re: Symmetric routes Hi, I did a little digging and it turns out that the QuickfixJ Converter creates an in-only exchange... Not sure why, but then again I am not very conversant with Quickfix and the message exchange patterns it supports. If the exchange can be made to be an in-out exchange and the the Quickfix event listener can also send responses to the endpoint, then you will not need to write the second route. Camel is fully capable of sending back responses (as we do in CXF) when using in-out exchanges. The camel-quickfix component does not support this. If you would like to have this capability and it is a valid usecase per quickfix message exchange patterns, I would be happen to add a Jira issue for the same. Can you please let men know. Cheers, Ashwin... - - Ashwin Karpe Apache Camel Committer Sr Principal Consultant FUSESource (a Progress Software Corporation subsidiary) http://fusesource.com Blog: http://opensourceknowledge.blogspot.com CamelOne 2011: http://fusesource.com/camel2011 - Bitte oeffnen Sie nicht jedes Mail-/Attachement. Achten Sie auf den Absender und beachten Sie die Sprache in der das Mail erstellt wurde. Sollten Sie z.B. ein Mail erhalten von einem Absender der normalerweise Mails in Deutsch
Re: Problems triggering a camel route in OSGi
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty hard...
My iPOJO object publishes an OSGi service which has a trigger() method that
is implemented as I wrote in my first post. This OSGi service is then used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to find my
webservice interface, I had to set the TCCL to the class loader that owns
that interface. I have now checked what TCCL is active when my trigger()
method is called from the webservice and it seems to be that interface's
classloader. I suspect that this might be problematic but I'm not exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I think I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also exposed as
webservice, and in this webservice impl class you invoke trigger method?
Or your camel router bundle also published as a OSGi service, from which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger method
looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer = mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In real
life,
the direct:start route is meant to be triggered via a published OSGi
service (actually through a web service call). However, this does not work
at all.
Whenever I try to call the trigger() method from somewhere else, the
mCamelContext member is null and I get a NPE when trying to create the
producer template. Why is that?
I realize that this might not be a Camel problem but a OSGi/iPOJO problem
but it's definitely related to Camel. I checked what class loader is being
used to for the mCamelContext instance and it turns out to be the
camel-spring bundle's class loader. Could that be related to my problems?
I am very confused about this and would appreciate any help,
/Bengt
-
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
Re: Problems triggering a camel route in OSGi
I added a system.out to see what this is in the two methods start() and
trigger() respectively. It turns out that this is different in those two
methods which I guess means that iPOJO has created two instances of my class
and in one of them I initialised the mCamelContext but in the other I
didn't. I now assume that this is a iPOJO problem (or a lack of
understanding on my part) and will see if I can get some advice on the Felix
mailing list - if you don't happen to know what's going on Freeman.
Thanks for your help,
/Bengt
2011/5/30 Bengt Rodehav be...@rodehav.com
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty hard...
My iPOJO object publishes an OSGi service which has a trigger() method that
is implemented as I wrote in my first post. This OSGi service is then used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to find
my webservice interface, I had to set the TCCL to the class loader that owns
that interface. I have now checked what TCCL is active when my trigger()
method is called from the webservice and it seems to be that interface's
classloader. I suspect that this might be problematic but I'm not exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I think I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also exposed
as webservice, and in this webservice impl class you invoke trigger method?
Or your camel router bundle also published as a OSGi service, from which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger method
looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer = mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In real
life,
the direct:start route is meant to be triggered via a published OSGi
service (actually through a web service call). However, this does not
work
at all.
Whenever I try to call the trigger() method from somewhere else, the
mCamelContext member is null and I get a NPE when trying to create the
producer template. Why is that?
I realize that this might not be a Camel problem but a OSGi/iPOJO problem
but it's definitely related to Camel. I checked what class loader is
being
used to for the mCamelContext instance and it turns out to be the
camel-spring bundle's class loader. Could that be related to my problems?
I am very confused about this and would appreciate any help,
/Bengt
-
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Connect at CamelOne May 24-26
The Open Source Integration
Re: Problems triggering a camel route in OSGi
Hi,
So far I'm not so sure it's a classloader issue.
My gut feeling is that somehow
mCamelContext = factory.createContext();
not get initialized correctly before your webservice invoke trigger
method.
Could you add print around
mCamelContext = factory.createContext();
to see if it really get initialized?
About you have to set classloader that owns that interface, I guess
it's another issue and already get fixed on cxf side[1] very recently,
please take a look at [2] to get more background about it.
[1]https://issues.apache.org/jira/browse/CXF-3512
[2]http://cxf.547215.n5.nabble.com/Multiple-endpoints-on-same-port-td4375160.html#a4375527
Freeman
On 2011-5-30, at 下午9:34, Bengt Rodehav wrote:
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty
hard...
My iPOJO object publishes an OSGi service which has a trigger()
method that
is implemented as I wrote in my first post. This OSGi service is
then used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the
container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to
find my
webservice interface, I had to set the TCCL to the class loader that
owns
that interface. I have now checked what TCCL is active when my
trigger()
method is called from the webservice and it seems to be that
interface's
classloader. I suspect that this might be problematic but I'm not
exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I
think I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle
implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice
call?
Do you mean your customer bundle which contain camel router also
exposed as
webservice, and in this webservice impl class you invoke trigger
method?
Or your camel router bundle also published as a OSGi service, from
which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to
classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the
bundle
context in my constructor from iPOJO. The actual routes are
created like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger
method
looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer =
mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In
real
life,
the direct:start route is meant to be triggered via a published
OSGi
service (actually through a web service call). However, this does
not work
at all.
Whenever I try to call the trigger() method from somewhere else, the
mCamelContext member is null and I get a NPE when trying to create
the
producer template. Why is that?
I realize that this might not be a Camel problem but a OSGi/iPOJO
problem
but it's definitely related to Camel. I checked what class loader
is being
used to for the mCamelContext instance and it turns out to be the
camel-spring bundle's class loader. Could that be related to my
problems?
I am very confused about this and would appreciate any help,
/Bengt
-
Freeman Fang
FuseSource
Email:ff...@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog:
Re: Problems triggering a camel route in OSGi
On 5/30/11 8:22 PM, Bengt Rodehav wrote: Whenever I try to call the trigger() method from somewhere else, the mCamelContext member is null and I get a NPE when trying to create the producer template. Why is that? Can you show use the stack trace of the NPE? -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang Weibo: willemjiang
Re: Problems triggering a camel route in OSGi
Hello Willem, Below is the stack trace. Line 251 of ExportTransService.java corresponds to the following line in the trigger() method: *ProducerTemplate producer = mCamelContext.createProducerTemplate();* /Bengt 2011-05-30 14:39:20,502 | ERROR | 366-85 - /trsws/ | DefaultErrorHandler | ache.camel.processor.CamelLogger 232 | Failed delivery for exchangeId: ID-IT-W2091-4336-1306758429476-3-1. Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException. Processed by failure processor: Channel[Wrap[se.digia.trs.service.error.IErrorService$$Proxy@1bf22b3] - se.digia.trs.service.error.IErrorService$$Proxy@1bf22b3] java.lang.NullPointerException at se.digia.trs.route.exporttrans.ExportTransService.__exportTransactions(ExportTransService.java:251) at se.digia.trs.route.exporttrans.ExportTransService.exportTransactions(ExportTransService.java) at se.digia.trs.route.exporttrans.IExportTransService$$Proxy.exportTransactions(Unknown Source) at se.digia.trs.route.webservice.impl.TrsWebServiceImpl.exportTransactions(TrsWebServiceImpl.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_25] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_25] at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_25] at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:322)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:224)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:167)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:77)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:77)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:99)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:77)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:299)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:208)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DefaultChannel.process(DefaultChannel.java:269)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:109)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:77)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:68)[89:org.apache.camel.camel-core:2.7.1] at org.apache.camel.component.cxf.CxfConsumer$1.asyncInvoke(CxfConsumer.java:96)[165:org.apache.camel.camel-cxf:2.7.1] at org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:72)[165:org.apache.camel.camel-cxf:2.7.1] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)[163:org.apache.cxf.bundle:2.3.3] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_25] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_25] at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)[163:org.apache.cxf.bundle:2.3.3] at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)[163:org.apache.cxf.bundle:2.3.3] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255)[163:org.apache.cxf.bundle:2.3.3] at
Re: Problems triggering a camel route in OSGi
Freeman,
Yes, I've logged around the createContext() call. I make this call in the
start() method and I can see that the mCamelContext variable has a valid
value. However, when the trigger() method is called (via the published OSGi
service) the mCamelContext is null.
I looked at your URL's . I'm a bit curious as to what the improvement really
means. When I initially tried to get camel-cxf working in Karaf, Willem
helped me and pointed out that I had to set the TCCL before I created the
context. That worked but to me this does not seem to be an OSGi friendly
solution. I do not think that one should have to care about the TCCL when in
an OSGi environment. It leads to all sorts of other problems. TCCL is one of
things I believe should be avoided in OSGi.
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
So far I'm not so sure it's a classloader issue.
My gut feeling is that somehow
mCamelContext = factory.createContext();
not get initialized correctly before your webservice invoke trigger method.
Could you add print around
mCamelContext = factory.createContext();
to see if it really get initialized?
About you have to set classloader that owns that interface, I guess it's
another issue and already get fixed on cxf side[1] very recently, please
take a look at [2] to get more background about it.
[1]https://issues.apache.org/jira/browse/CXF-3512
[2]
http://cxf.547215.n5.nabble.com/Multiple-endpoints-on-same-port-td4375160.html#a4375527
Freeman
On 2011-5-30, at 下午9:34, Bengt Rodehav wrote:
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty hard...
My iPOJO object publishes an OSGi service which has a trigger() method
that
is implemented as I wrote in my first post. This OSGi service is then used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to find
my
webservice interface, I had to set the TCCL to the class loader that owns
that interface. I have now checked what TCCL is active when my trigger()
method is called from the webservice and it seems to be that interface's
classloader. I suspect that this might be problematic but I'm not exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I think I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle
implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also exposed
as
webservice, and in this webservice impl class you invoke trigger method?
Or your camel router bundle also published as a OSGi service, from which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to classloading. I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
trigger() method is called that in turn will send an exchange to the
direct:start endpoint that will do the real work. The trigger method
looks
like this:
* public void trigger() {*
*
System.out.println(trigger, mCamelContext: + mCamelContext);
ProducerTemplate producer = mCamelContext.createProducerTemplate();*
*MapString, Object headers = new HashMapString, Object();*
*// ...populate headers*
*String body;*
*// ... initialize body*
*producer.sendBodyAndHeaders(direct:start, body, headers);*
* }*
*
*
Dropping the file in localdir is just for testing purposes. In real
life,
the direct:start
Re: Problems triggering a camel route in OSGi
I solved the problem.
I had misunderstood the iPOJO annotations and exposed my service as follows:
@Provides(specifications = { IService.class }, strategy = SERVICE)
The problem is that I used the SERVICE strategy when I should have used
SINGLETON - which is also the default. When using SERVICE, each invoker
gets its own instance which is why the value of my member variable didn't
stick. When I changed this, the instance is the same in the start() method
and the trigger() mehtod and everything works as it should.
Stupid mistake on my part. Thanks for all your help.
/Bengt
2011/5/30 Bengt Rodehav be...@rodehav.com
Freeman,
Yes, I've logged around the createContext() call. I make this call in the
start() method and I can see that the mCamelContext variable has a valid
value. However, when the trigger() method is called (via the published OSGi
service) the mCamelContext is null.
I looked at your URL's . I'm a bit curious as to what the improvement
really means. When I initially tried to get camel-cxf working in Karaf,
Willem helped me and pointed out that I had to set the TCCL before I created
the context. That worked but to me this does not seem to be an OSGi friendly
solution. I do not think that one should have to care about the TCCL when in
an OSGi environment. It leads to all sorts of other problems. TCCL is one of
things I believe should be avoided in OSGi.
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
So far I'm not so sure it's a classloader issue.
My gut feeling is that somehow
mCamelContext = factory.createContext();
not get initialized correctly before your webservice invoke trigger
method.
Could you add print around
mCamelContext = factory.createContext();
to see if it really get initialized?
About you have to set classloader that owns that interface, I guess it's
another issue and already get fixed on cxf side[1] very recently, please
take a look at [2] to get more background about it.
[1]https://issues.apache.org/jira/browse/CXF-3512
[2]
http://cxf.547215.n5.nabble.com/Multiple-endpoints-on-same-port-td4375160.html#a4375527
Freeman
On 2011-5-30, at 下午9:34, Bengt Rodehav wrote:
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty
hard...
My iPOJO object publishes an OSGi service which has a trigger() method
that
is implemented as I wrote in my first post. This OSGi service is then
used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to find
my
webservice interface, I had to set the TCCL to the class loader that owns
that interface. I have now checked what TCCL is active when my trigger()
method is called from the webservice and it seems to be that interface's
classloader. I suspect that this might be problematic but I'm not exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I think
I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle
implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fang freeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also exposed
as
webservice, and in this webservice impl class you invoke trigger method?
Or your camel router bundle also published as a OSGi service, from which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to classloading.
I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created
like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange theExchange) throws Exception {
trigger();
}
});
from(direct:start).process()to(ftp:);
}
}
Both routes works fine. When dropping a file in the localdir, the
Re: Problems triggering a camel route in OSGi
Hi,
It's good to see you finally find the solution.
You maybe the first one who want to start a camel context within iPOJO
in this mailing list. Do you fancy to write a blog about it? We can add
article link for it.
On 5/31/11 4:05 AM, Bengt Rodehav wrote:
I solved the problem.
I had misunderstood the iPOJO annotations and exposed my service as follows:
@Provides(specifications = { IService.class }, strategy = SERVICE)
The problem is that I used the SERVICE strategy when I should have used
SINGLETON - which is also the default. When using SERVICE, each invoker
gets its own instance which is why the value of my member variable didn't
stick. When I changed this, the instance is the same in the start() method
and the trigger() mehtod and everything works as it should.
Stupid mistake on my part. Thanks for all your help.
/Bengt
2011/5/30 Bengt Rodehavbe...@rodehav.com
Freeman,
Yes, I've logged around the createContext() call. I make this call in the
start() method and I can see that the mCamelContext variable has a valid
value. However, when the trigger() method is called (via the published OSGi
service) the mCamelContext is null.
I looked at your URL's . I'm a bit curious as to what the improvement
really means. When I initially tried to get camel-cxf working in Karaf,
Willem helped me and pointed out that I had to set the TCCL before I created
the context. That worked but to me this does not seem to be an OSGi friendly
solution. I do not think that one should have to care about the TCCL when in
an OSGi environment. It leads to all sorts of other problems. TCCL is one of
things I believe should be avoided in OSGi.
/Bengt
2011/5/30 Freeman Fangfreeman.f...@gmail.com
Hi,
So far I'm not so sure it's a classloader issue.
My gut feeling is that somehow
mCamelContext = factory.createContext();
not get initialized correctly before your webservice invoke trigger
method.
Could you add print around
mCamelContext = factory.createContext();
to see if it really get initialized?
About you have to set classloader that owns that interface, I guess it's
another issue and already get fixed on cxf side[1] very recently, please
take a look at [2] to get more background about it.
[1]https://issues.apache.org/jira/browse/CXF-3512
[2]
http://cxf.547215.n5.nabble.com/Multiple-endpoints-on-same-port-td4375160.html#a4375527
Freeman
On 2011-5-30, at 下午9:34, Bengt Rodehav wrote:
Thanks for your reply Freeman.
I'll try to explain although I found even the explaining is pretty
hard...
My iPOJO object publishes an OSGi service which has a trigger() method
that
is implemented as I wrote in my first post. This OSGi service is then
used
by another iPOJO object that has the service injected by iPOJO using
@Requires.
The latter iPOJO object instantiates a camel route of its own using
camel-cxf to publish a web service that I test from outside the container
using soapUI.
I did have problems getting camel-cxf to work. In order for Camel to find
my
webservice interface, I had to set the TCCL to the class loader that owns
that interface. I have now checked what TCCL is active when my trigger()
method is called from the webservice and it seems to be that interface's
classloader. I suspect that this might be problematic but I'm not exactly
sure why or how I can fix it.
I hope I answered your question. Of your two alternate answers I think
I'm
doing what you describe in the second answer (my camel router bundle
publishes an OSGi service that is being called from the bundle
implementing
the web service using CXF).
/Bengt
2011/5/30 Freeman Fangfreeman.f...@gmail.com
Hi,
Could you elaborate how you invoke trigger method from webservice call?
Do you mean your customer bundle which contain camel router also exposed
as
webservice, and in this webservice impl class you invoke trigger method?
Or your camel router bundle also published as a OSGi service, from which
other code can invoke trigger method?
Freeman
On 2011-5-30, at 下午8:22, Bengt Rodehav wrote:
I have a very strange problem that is probably related to classloading.
I
use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
I create my camel context like this:
@Validate
public void start() {
CamelContextFactory factory = new CamelContextFactory();
factory.setBundleContext(getBundleContext());
mCamelContext = factory.createContext();
RouteBuilder builder = createRouteBuilder();
try {
mCamelContext.addRoutes(builder);
} catch (Exception e) {
e.printStackTrace();
}
try {
mCamelContext.start();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(start, mCamelContext: + mCamelContext);
}
It is created when the iPOJO component becomes valid. I get the bundle
context in my constructor from iPOJO. The actual routes are created
like
this:
private RouteBuilder createRouteBuilder() {
RouteBuilder builder = new RouteBuilder() {
from(file:localdir).process(new Processor() {
public void process(Exchange
Re: Unit test camel with activeMQ
take a look at the camel-jms unit tests. they should get you started with
setting up AMQ and asserting message flow, etc...
here is a good one to start with...
https://svn.apache.org/repos/asf/camel/trunk/components/camel-jms/src/test/java/org/apache/camel/component/jms/JmsRouteTest.java
hbellat wrote:
Hello,
I used Junit for java program but I need some examples to understand how
it works in camel with activeMQ
I wrote a simple camel.xml as follow :
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=activemq:start/
bean ref=MyBean method=route /
to uri=activemq:finish/
/route
/camelContext
and MyBean.java is :
public class MyBean {
public void route(Exchange message){
String name = message.getIn().getBody(String.class);
name=test;
message.getOut().setBody(name);
}
}
In my route I send any string like my unit Test, this string received by
the bean and affecte test in my String and route it to activemq:finish.
How can I write a unit test for that simple code ?
In my test I was wondring if my activemq must be started ?
I will appreciate your help.
-
Ben O'Day
IT Consultant -http://benoday.blogspot.com
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-camel-with-activeMQ-tp4438580p4440861.html
Sent from the Camel - Users mailing list archive at Nabble.com.
