Re: CXF, Camel Transport, and Can't find InputStream in message
Hi Jérémie, I just applied your patch, it's a part of Camel 2.6-SNAPSHOT now. On 10/24/10 12:22 AM, Jérémie wrote: I have created CAMEL-3269 https://issues.apache.org/activemq/browse/CAMEL-3269 On Sat, Oct 23, 2010 at 4:13 PM, Willem Jiangwillem.ji...@gmail.comwrote: Current camel-cxf component just treat the MEP as InOut, so you can get the such error. Please feel free to create a JIRA[1], so we can keep track of this issue. [1]https://issues.apache.org/activemq/browse/CAMEL On 10/23/10 7:34 PM, Jérémie wrote: Hello, I'm using a jaws proxy with camel transport for cxf in order to implement a webservice. Sometimes cxf can't process the response of the camel route, and fail with Can't find InputStream in message. after some research, i suppose it's a conflict with CamelConduit and the MEP of the message : - CamelConduit, through CxfMessageHelper.getCxfInMessage is looking for the Out message of the exchange - When the route has only one processor likechoice,setBody, transform, the Out part of the exchange is empty, and so cxf fail - When the route is a pipeline, the in message is automatically copied to the out message, so cxf successfully handle the message i have attached a test-case and a simple patch, but I'm not sure that it's the proper way to correct this error : In getCxfInMessage, if there is no out part in the current exchange, i take the in part. Maybe the CamelConduit should use a ProducerTemplate and not a processor instance… Or maybe I'm not using it the proper way :) Jeremie -- Willem -- Open Source Integration: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: http://twitter.com/willemjiang -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
Re: camel 2.4 and cxf issue - works in 2.2
It looks like the spring namespace handler of
http://camel.apache.org/schema/cxf; can't not be loaded rightly.
This namespace handler is part of camel-cxf, please check the installed
bundles to make sure camel-cxf bundle is installed rightly.
On 10/24/10 2:05 AM, Hossein wrote:
Hello,
We were using fusesource 4.2 SP 1 and have some cxf endpoint that can be
deployed into SMX 4.2 SP 1 with no problem. Just switching to fusesource 4.3
which includes camel 2.4 and running into issue deploying into SMX. I think
this has to do with schema being used, but don't really know how to resolve
issue. All help is appreciated.
-Basically have camel-cxf.xml with the endpoint that includes:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xmlns:cxf=http://camel.apache.org/schema/cxf;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://camel.apache.org/schema/cxf
http://camel.apache.org/schema/cxf/camel-cxf.xsd;
import resource=classpath:META-INF/cxf/cxf.xml/
import resource=classpath:META-INF/cxf/cxf-extension-soap.xml/
import resource=classpath:META-INF/cxf/cxf-extension-http-jetty.xml/
-Then in our camel-route.xml we have the following:
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:camel=http://camel.apache.org/schema/spring;
xsi:schemaLocation=
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd;
xmlns:context=http://www.springframework.org/schema/context;
import resource=classpath:META-INF/spring/camel-cxf.xml/
- Build / deploy
Build goes through with no problem. However, when deploying into SMX, I get
the following:
FROM SMX CONSOLE:ka...@root Exception in thread
SpringOsgiExtenderThread-22 java.lang.IllegalStateException: BeanFactory
not initialized or already closed - call 'refresh' before accessing beans
via the ApplicationContext
at
org.springframework.context.support.AbstractRefreshableApplicationContext.getBeanFactory(AbstractRefreshableApplicationContext.java:171)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.close(DependencyWaiterApplicationContextExecutor.java:345)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.fail(DependencyWaiterApplicationContextExecutor.java:401)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:287)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:175)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:718)
at java.lang.Thread.run(Thread.java:619)
FROM servicemix.log FILE:
2010-10-23,18:03:34.589 | INFO | [Karaf Shell Console Thread] |
org.springframework.osgi.extender.support.DefaultOsgiApplicationContextCreator
|
org.springframework.osgi.extender.support.DefaultOsgiApplicationContextCreator
67 | 73 - org.springframework.osgi.extender - 1.2.0 | Discovered
configurations {osgibundle:/META-INF/spring/*.xml} in bundle [PORTAL - Flow
A - flowA-RVRService - OSGi - CXF RVR Service (flowA-RVRService)]
2010-10-23,18:03:34.591 | INFO | [SpringOsgiExtenderThread-22] |
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext |
org.springframework.context.support.AbstractApplicationContext 456 | 62 -
org.springframework.context - 3.0.3.RELEASE | Refreshing
OsgiBundleXmlApplicationContext(bundle=flowA-RVRService,
config=osgibundle:/META-INF/spring/*.xml): startup date [Sat Oct 23 18:03:34
GMT 2010]; root of context hierarchy
2010-10-23,18:03:34.591 | INFO | [SpringOsgiExtenderThread-22] |
org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext |
org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext
359 | 62 - org.springframework.context - 3.0.3.RELEASE | Unpublishing
application context OSGi service for bundle PORTAL - Flow A -
Re: Jetty Component: HttpServletRequest losts HTTP Post parameters
You can't use the HttpServletRequest to get the request parameter map, as the HttpServletRequest input stream is consumed by camel if the request content type is application/x-www-form-urlencoded. It not a bug, you can consider that the HttpServletRequest's input stream can't be consumed twice. On 10/28/10 6:45 PM, Sebastian Münz wrote: Okay, i get it! By converting the Exchange-Body I get the HTTP_QUERY String. So i get the information which parameters are sent. String exchangeBody = httpExchange.getIn().getBody(String.class); Result: property1=oneproperty2=twoproperty3=threeproperty4=four Nonetheless I think the parameter map should be in the HttpServletRequest after convertion! Isn't it a bug? Best regards - Sebastian -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
Re: XMPP communication not closed and new message rejected
I just checked the code of XmppPrivateChatProducer, it doesn't close the connection even the Producer is stopped. It's a bug of XMPP, I just create a JIRA[1] for it. [1]http://camel.465427.n5.nabble.com/XMPP-communication-not-closed-and-new-message-rejected-td3236657.html#a3236657 On 10/27/10 9:03 PM, Alesque wrote: I'm using the Recipient List pattern to route dynamically messages to different XMPP accounts. I'm experienced the same issue. I noticed XMPP connections remain open in ejabberd. So the first message is routed, and when others occured, I've got an Exception because accounts are already connected with the default resource identifier Camel. If I set a resource identifier (UUID) randomly for each recipient that works, but connections remain open in ejabberd. Why XMPP connections remain open? Is this a bug? Is this the expected behaviour? Perhaps connections are pooled and the algorithm to get the connection related to a specific URI endpoint is broken. Any help would be greatly appreciated, Regards, Alexandre -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
Re: Camel 2.5.0 released
The highlights below in the mail are actually from Camel 2.4 You can read the 2.5 highlights here http://camel.apache.org/2010/10/31/camel-250-released.html I would add to that the new Jasypt component as a highlight http://camel.apache.org/jasypt.html And the fact Camel wont log passwords from endpoint configurations in the logs as they are now masked The operations team would like that :) On Mon, Nov 1, 2010 at 4:52 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: The Apache Camel project [1] issued this week another minor release camel-2.5.0 [2]. We are extremely grateful to the community for the continued support and the contributions. The 2.5.0 release (see release notes for details [3]) includes approx 300 issues resolved (new features, improvements and bug fixes) among which, in no particular order: • Fully non blocking Asynchronous Routing Engine which all EIPs and some Camel Components supported. • OSGi blueprint is now supported • The camel-spring module now supports OSGi out of box. • Spring 3.0.3 is now the default Spring version used by Camel. • Added new contextScan to scan the Registry for RouteBuilder instances, just as scanning the classpath etc. • Manually started routes is now also Graceful Shutdown by Camel • Fixed issue using RouteContextRef with multiple CamelContext from the same Spring ApplicationContext. • Spring Security is upgrade to spring security 3.0.3.RELEASE. • Many fixes in components like Bindy, JMS, HTTP, FTP, Quartz, CSV • Added a Debugger API to be leveraged by 3rd party tooling. • Improvements for managing Camel using JMX. • Upgraded to latest release of Scala 2.8.0RC7 in Scala DSL • Introduced ProcessorFactory to be able to use a custom factory to be able to manipulate Processor creation process. For example to add additional outputs or manipulate the route model. • Properties component can lookup java.util.Properties from the Registry using the ref: prefix. Download [4] Camel now and enjoy the ride! Hadrian [1] http://camel.apache.org/ [2] http://camel.apache.org/2010/10/31/camel-250-released.html [3] http://camel.apache.org/camel-250-release.html [4] http://camel.apache.org/download.html -- 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/
Re: XMPP communication not closed and new message rejected
On 11/1/10 4:17 PM, Willem Jiang wrote: I just checked the code of XmppPrivateChatProducer, it doesn't close the connection even the Producer is stopped. It's a bug of XMPP, I just create a JIRA[1] for it. [1]http://camel.465427.n5.nabble.com/XMPP-communication-not-closed-and-new-message-rejected-td3236657.html#a3236657 The JIRA link should be https://issues.apache.org/activemq/browse/CAMEL-3298 BTW, I didn't have a chance to test the patch on XMPP Server. Maybe we need to close the connection when the producer finish to send the message. On 10/27/10 9:03 PM, Alesque wrote: I'm using the Recipient List pattern to route dynamically messages to different XMPP accounts. I'm experienced the same issue. I noticed XMPP connections remain open in ejabberd. So the first message is routed, and when others occured, I've got an Exception because accounts are already connected with the default resource identifier Camel. If I set a resource identifier (UUID) randomly for each recipient that works, but connections remain open in ejabberd. Why XMPP connections remain open? Is this a bug? Is this the expected behaviour? Perhaps connections are pooled and the algorithm to get the connection related to a specific URI endpoint is broken. Any help would be greatly appreciated, Regards, Alexandre -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
Re: CXF Startup issue with Camel in OSGI runtime
Hi, What kind of CXF bundle are you using? Did you installed the cxf-bundle bundle? Here is a FAQ entry[1] may help you too. [1]https://cwiki.apache.org/CAMEL/how-to-avoid-importing-bunch-of-cxf-packages-when-start-up-the-camel-cxf-endpoint-from-osgi-platform-.html On 10/29/10 8:35 PM, unmarshall wrote: Hi All, I have an equinox based OSGI runtime. In that i am using Apache Camel 2.4.0 and CXF - 2.2.11 In the spring XML configuration file i have the following include statements: import resource=classpath*:META-INF/cxf/cxf.xml / import resource=classpath*:META-INF/cxf/cxf-extension-soap.xml / import resource=classpath*:META-INF/cxf/cxf-extension-http.xml/ import resource=classpath*:META-INF/cxf/osgi/cxf-extension-osgi.xml/ When the osgi runtime starts then it throws the following exception: Oct 29, 2010 5:20:10 PM org.apache.cxf.bus.spring.SpringBusFactory createApplicationContext WARNING: Initial attempt to create application context was unsuccessful. org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [META-INF/cxf/cxf.xml]; nested exception is java.io.FileNotFoundException: class path resource [META-INF/cxf/cxf.xml] cannot be opened because it does not exist at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:341) at org.apache.cxf.bus.spring.ControlledValidationXmlBeanDefinitionReader.loadBeanDefinitions(ControlledValidationXmlBeanDefinitionReader.java:131) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) at org.springframework.context.support.AbstractXmlApplicationContext.loadBeanDefinitions(AbstractXmlApplicationContext.java:122) at org.apache.cxf.bus.spring.BusApplicationContext.loadBeanDefinitions(BusApplicationContext.java:262) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397) at org.apache.cxf.bus.spring.BusApplicationContext.init(BusApplicationContext.java:91) at org.apache.cxf.bus.spring.SpringBusFactory.createApplicationContext(SpringBusFactory.java:102) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:93) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:86) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:64) at org.apache.cxf.bus.spring.SpringBusFactory.createBus(SpringBusFactory.java:53) at org.apache.cxf.transport.servlet.CXFServlet.updateContext(CXFServlet.java:136) at org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.java:104) at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:73) at org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFServlet.java:84) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.init(ServletRegistration.java:49) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.registerServlet(ProxyServlet.java:177) at org.eclipse.equinox.http.servlet.internal.HttpServiceImpl.registerServlet(HttpServiceImpl.java:66) at com.sap.pi.composite.syn.internal.activator.TrackingComponent.startup(TrackingComponent.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:210) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:139) at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.build(ServiceComponentProp.java:329) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponent(InstanceProcess.java:580) at org.eclipse.equinox.internal.ds.InstanceProcess.buildComponents(InstanceProcess.java:196) at org.eclipse.equinox.internal.ds.Resolver.buildNewlySatisfied(Resolver.java:431) at org.eclipse.equinox.internal.ds.Resolver.enableComponents(Resolver.java:213) at org.eclipse.equinox.internal.ds.SCRManager.performWork(SCRManager.java:800) at
Re: Enabling tracing in production
On 10/30/10 4:49 PM, Bengt Rodehav wrote: I have a similar situation but I'm not using Spring - I use Java DSL and iPOJO. I have my own tracer that I can publish as an OSGi service using iPOJO. I want to accomplish the following. My other services shall have optional service dependencies to my tracer. This means that if my custom tracer is available then it should be used, otherwise the default tracer should be used. However, just publishing my tracer and requiring it in my other components does not automatically cause Camel to use it. I have to to the following: getContext().addInterceptStrategy(mTracer); getContext().setTracing(false); In other words I explicitly set my tracer to be used, I then disable tracing since the first line seems to automatically enable tracing. I then use JMX to enable/disable tracing. I was hoping the above two lines were unnecessary and that merely the existence of a tracer should cause Camel to use it. Is that a Spring specific functionality? I was hoping that any way that an OSGi service was published/consumed would work? If you take a look at the code of AbstractCamelContextFactoryBean.afterPropertiesSet() which is used to set the camel context from the sprint configuration, you will find it calls the same code. If you don't want to write upper code twice, you may need to write a Factory to create the camel context instance in the same way and look up the tracer from the OSGi service registry. [1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-core-xml/src/main/java/org/apache/camel/core/xml/AbstractCamelContextFactoryBean.java /Bengt 2010/10/30 Richard Kettelerijrichardkettele...@gmail.com You don't have to add a Tracer to your Spring context yourself. Camel adds one automatically if you have a CamelContext declared in Spring. Also your don't have to do anything with the trace option in your Spring context. I find that the easiest way to enable/disable tracing in production is through JMX. Just navigate to the CamelContext MBean and modify the tracing attribute. Additionally you can determine what should be traced by modifying a few options in the Tracer MBean. - Richard Kettelerij, http://github.com/rkettelerij -- View this message in context: http://camel.465427.n5.nabble.com/Enabling-tracing-in-production-tp3243013p3243143.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
Re: camel 2.4 and cxf issue - works in 2.2
Willem, On 9/24/2010, I put-in a JIRA with FUSESOURCE; DEV-2729. This problem had to do with camel-2.4.0-fuse-01-00-features.xml file and I was able to do a workaround on it. Here is a snippet of the JIRA ...the problem appears to be due to wrong version of http being used in camel-2.4.0-fuse-01-00-features.xml. Commented out line 75 of above ( feature version='2.4.0-fuse-01-00'http/feature )... --- Hossein Amerkashi -- View this message in context: http://camel.465427.n5.nabble.com/camel-2-4-and-cxf-issue-works-in-2-2-tp3233662p3244904.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: camel 2.4 and cxf issue - works in 2.2
Hi Hossein Thanks for reporting this, it save lots of time to dig the issue. I will make sure the patch to be a part of Camel 2.6.0. On 11/1/10 7:35 PM, Hossein wrote: Willem, On 9/24/2010, I put-in a JIRA with FUSESOURCE; DEV-2729. This problem had to do with camel-2.4.0-fuse-01-00-features.xml file and I was able to do a workaround on it. Here is a snippet of the JIRA ...the problem appears to be due to wrong version of http being used in camel-2.4.0-fuse-01-00-features.xml. Commented out line 75 of above ( feature version='2.4.0-fuse-01-00'http/feature )... --- Hossein Amerkashi -- Willem -- FuseSource Web: http://www.fusesource.com Blog:http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
Re: Enabling tracing in production
Thanks Willem - will take a look. BTW, do you have any hints as to whether it's possible to reconfigure a tracer on-the-fly as I described in an earlier post? /Bengt 2010/11/1 Willem Jiang willem.ji...@gmail.com On 10/30/10 4:49 PM, Bengt Rodehav wrote: I have a similar situation but I'm not using Spring - I use Java DSL and iPOJO. I have my own tracer that I can publish as an OSGi service using iPOJO. I want to accomplish the following. My other services shall have optional service dependencies to my tracer. This means that if my custom tracer is available then it should be used, otherwise the default tracer should be used. However, just publishing my tracer and requiring it in my other components does not automatically cause Camel to use it. I have to to the following: getContext().addInterceptStrategy(mTracer); getContext().setTracing(false); In other words I explicitly set my tracer to be used, I then disable tracing since the first line seems to automatically enable tracing. I then use JMX to enable/disable tracing. I was hoping the above two lines were unnecessary and that merely the existence of a tracer should cause Camel to use it. Is that a Spring specific functionality? I was hoping that any way that an OSGi service was published/consumed would work? If you take a look at the code of AbstractCamelContextFactoryBean.afterPropertiesSet() which is used to set the camel context from the sprint configuration, you will find it calls the same code. If you don't want to write upper code twice, you may need to write a Factory to create the camel context instance in the same way and look up the tracer from the OSGi service registry. [1] https://svn.apache.org/repos/asf/camel/trunk/components/camel-core-xml/src/main/java/org/apache/camel/core/xml/AbstractCamelContextFactoryBean.java /Bengt 2010/10/30 Richard Kettelerijrichardkettele...@gmail.com You don't have to add a Tracer to your Spring context yourself. Camel adds one automatically if you have a CamelContext declared in Spring. Also your don't have to do anything with the trace option in your Spring context. I find that the easiest way to enable/disable tracing in production is through JMX. Just navigate to the CamelContext MBean and modify the tracing attribute. Additionally you can determine what should be traced by modifying a few options in the Tracer MBean. - Richard Kettelerij, http://github.com/rkettelerij -- View this message in context: http://camel.465427.n5.nabble.com/Enabling-tracing-in-production-tp3243013p3243143.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
Re: Abstracting Routes using Components
jstrachan' wrote: So when we're routing into a Protocol from the outside, we need to decide what the URI parameters map to - is it configuring properties on the protocol bean, or passing headers into the message? It could go either way. Typically we tend to configure a component (which can have many possible endpoints) once through dependency injection (spring/guice/jndi etc), then use uri parameters to configure the actual Endpoint objects. So when a Protocol is a Component we should follow suit; if you want different Protocol instances with different configurations (with their own sets of endpoints) then use different dependency injected beans with different URI schemes. So in your previous example we might use URIs fooBar://in fooNoBar://in on different component instances configured. When a Protocol is exposed as just a single Endpoint (with a fixed in endpoint), then the act of creating the Endpoint from the Protocol could configure a new instance of the Protocol bean using URI query parameters. So in your example, route:foo?foo=bar could be instantiating the foo bean, setting the foo property then invoking it's 'in' endpoint. Ok, I see, that makes sense. When a protocol is a component, the component 'owns' the route config. Since there are multiple endpoints, using a shorthand to configure properties on the component level is plain wrong as it could result in erraditic behaviour. If the Protocol component should support a shorthand notation, passing the values as headers would be the only option I guess. jstrachan wrote: Incidentally, maybe using the term Protocol for the Component or Endpoint use cases above is confusing. Maybe we say a Protocol is-a Component with a URI scheme and multiple public input/output endpoints and for the Endpoint case (in your example) we just call that a Route Endpoint - I.e. turning a named RouteBuilder bean into an Endpoint (then sending to it's first 'from')? Good point, distinct names for both concepts. I'm starting to wonder though whether the Route Endpoint would still be of use when there is a protocol component. The only benefit of having a Route Endpoint is that you could configure properties through URI parameters. I don't even know whether there is be a real use case for that. Maybe the concept of passing header values via a shorthand notation is already all the customer needs. I guess we'll know once the customer will start the real implementation. But I would definitively prefer to reusing the protocol concept as it fits the core requirement, which is creating reusable components with proper endpoint encapsulation / scoping. -- View this message in context: http://camel.465427.n5.nabble.com/Abstracting-Routes-using-Components-tp3234703p3245266.html Sent from the Camel - Users mailing list archive at Nabble.com.
File : recursive + noop = no more idempotent
When mounting this route from(file://C://?noop=true).to(Processor); Only new files message are send to the Processor but when using from(file://C:/?noop=truerecursive=true).to(Processor); all files are send even if they haven't been checked before. Is this a correct behavior ? Thank you for any clarifications Robbie -- View this message in context: http://camel.465427.n5.nabble.com/File-recursive-noop-no-more-idempotent-tp3245321p3245321.html Sent from the Camel - Users mailing list archive at Nabble.com.
how to handle exceptions thrown by camel:choice
Hi all, I am a newbie to Camel and recently I've been stuck in this problem(I am using Camel with Spring): I defined an errorHandler in the CamelContext tag and I want it to be applied to all of my routes. In one of my route, I use camel: when and inside of that I bind a method in a POJO as the predicate. The problem is that when the method throws an exception, it is not handle by the errorHandler, instead, the exception is added to the exchange and the route continues. Example code: camel:camelContext id=context errorHandlerRef=myHandler camel:route id=myRoute camel:choice camel:when camel:method beanType=MyClass method=myMethodThatThrowsException/ do something... /camel:when camel:otherwise do something else... /camel:otherwise /camel:choice /camel:route other routes... /camel:camelContext bean id=myHandler class=org.apache.camel.builder.DeadLetterChannelBuilder proeprty name=redeliveryPolicy ref=myPolicy / property name=onRedelivery ref=myAlert / property name=deadLetterUri value=mock:dead / /bean bean id=myPolicy ... /bean bean id=myAlert ... /bean Is there a way that I can handle the exception thrown by myMethodThatThrowsException using myHandler? Please let me know if I missed anything. Any suggestion is appreciated! Best Yiming -- View this message in context: http://camel.465427.n5.nabble.com/how-to-handle-exceptions-thrown-by-camel-choice-tp3245484p3245484.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: XMPP communication not closed and new message rejected
If an XMPP endpoint is connected to both an incoming route and an outgoing route, the connection shouldn't be closed when the producer finishes. Perhaps it can be an option, like the Mina connector? Don On Mon, Nov 1, 2010 at 5:03 AM, Willem Jiang willem.ji...@gmail.com wrote: On 11/1/10 4:17 PM, Willem Jiang wrote: I just checked the code of XmppPrivateChatProducer, it doesn't close the connection even the Producer is stopped. It's a bug of XMPP, I just create a JIRA[1] for it. [1]http://camel.465427.n5.nabble.com/XMPP-communication-not-closed-and-new-message-rejected-td3236657.html#a3236657 The JIRA link should be https://issues.apache.org/activemq/browse/CAMEL-3298 BTW, I didn't have a chance to test the patch on XMPP Server. Maybe we need to close the connection when the producer finish to send the message. On 10/27/10 9:03 PM, Alesque wrote: I'm using the Recipient List pattern to route dynamically messages to different XMPP accounts. I'm experienced the same issue. I noticed XMPP connections remain open in ejabberd. So the first message is routed, and when others occured, I've got an Exception because accounts are already connected with the default resource identifier Camel. If I set a resource identifier (UUID) randomly for each recipient that works, but connections remain open in ejabberd. Why XMPP connections remain open? Is this a bug? Is this the expected behaviour? Perhaps connections are pooled and the algorithm to get the connection related to a specific URI endpoint is broken. Any help would be greatly appreciated, Regards, Alexandre -- Willem -- FuseSource Web: http://www.fusesource.com Blog: http://willemjiang.blogspot.com (English) http://jnn.javaeye.com (Chinese) Twitter: willemjiang
unit testing Spring XML route
I have a route defined in XML that I want to unit test. Is there a way to do this? I have found CamelSpringTestSupport, but I am not sure that is what I want. When I run a unit test that extends CamelSpringTestSupport I get the following stack trace. org.apache.camel.CamelExecutionException: Exception occurred during execution on the exchange: Exchange[Message: HELLO WORLD] at org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1156) at org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:456) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:441) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:437) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:125) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:341) at com.x.y.z.RecipientXmlTest.testTest(RecipientXmlTest.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at org.apache.camel.test.TestSupport.runBare(TestSupport.java:65) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.camel.CamelExchangeException: No consumers available on endpoint: Endpoint[direct://start]. Exchange[Message: HELLO WORLD] at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:56) at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:99) at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:91) at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85) at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:333) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:208) at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:154) at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:123) ... 22 more
Re: unit testing Spring XML route
Figured it out using the page http://camel.apache.org/testing.html and section Spring Test with XML Config Example. On Mon, Nov 1, 2010 at 4:16 PM, Mark Webb elihusma...@gmail.com wrote: I have a route defined in XML that I want to unit test. Is there a way to do this? I have found CamelSpringTestSupport, but I am not sure that is what I want. When I run a unit test that extends CamelSpringTestSupport I get the following stack trace. org.apache.camel.CamelExecutionException: Exception occurred during execution on the exchange: Exchange[Message: HELLO WORLD] at org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1156) at org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:456) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:441) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:437) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:125) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:341) at com.x.y.z.RecipientXmlTest.testTest(RecipientXmlTest.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at org.apache.camel.test.TestSupport.runBare(TestSupport.java:65) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.camel.CamelExchangeException: No consumers available on endpoint: Endpoint[direct://start]. Exchange[Message: HELLO WORLD] at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:56) at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:99) at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:91) at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85) at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:333) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:208) at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:154) at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:123) ... 22 more
Re: Camel 2.5.0 released
Cut and past from the wrong location. Apologies for the mistake. Claus, thanks for the correction! Hadrian On Nov 1, 2010, at 4:45 AM, Claus Ibsen wrote: The highlights below in the mail are actually from Camel 2.4 You can read the 2.5 highlights here http://camel.apache.org/2010/10/31/camel-250-released.html I would add to that the new Jasypt component as a highlight http://camel.apache.org/jasypt.html And the fact Camel wont log passwords from endpoint configurations in the logs as they are now masked The operations team would like that :) On Mon, Nov 1, 2010 at 4:52 AM, Hadrian Zbarcea hzbar...@gmail.com wrote: The Apache Camel project [1] issued this week another minor release camel-2.5.0 [2]. We are extremely grateful to the community for the continued support and the contributions. The 2.5.0 release (see release notes for details [3]) includes approx 300 issues resolved (new features, improvements and bug fixes) among which, in no particular order: • Fully non blocking Asynchronous Routing Engine which all EIPs and some Camel Components supported. • OSGi blueprint is now supported • The camel-spring module now supports OSGi out of box. • Spring 3.0.3 is now the default Spring version used by Camel. • Added new contextScan to scan the Registry for RouteBuilder instances, just as scanning the classpath etc. • Manually started routes is now also Graceful Shutdown by Camel • Fixed issue using RouteContextRef with multiple CamelContext from the same Spring ApplicationContext. • Spring Security is upgrade to spring security 3.0.3.RELEASE. • Many fixes in components like Bindy, JMS, HTTP, FTP, Quartz, CSV • Added a Debugger API to be leveraged by 3rd party tooling. • Improvements for managing Camel using JMX. • Upgraded to latest release of Scala 2.8.0RC7 in Scala DSL • Introduced ProcessorFactory to be able to use a custom factory to be able to manipulate Processor creation process. For example to add additional outputs or manipulate the route model. • Properties component can lookup java.util.Properties from the Registry using the ref: prefix. Download [4] Camel now and enjoy the ride! Hadrian [1] http://camel.apache.org/ [2] http://camel.apache.org/2010/10/31/camel-250-released.html [3] http://camel.apache.org/camel-250-release.html [4] http://camel.apache.org/download.html -- 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/
OnException appears to roll back message state - Need help in understanding
Hi - I am need of some help in understanding more about exception handling.
I am using Camel 2.2 inside of Servicemix 3.3.2 (along with XMLBeans and
Spring).
What I need to happen is that the nature of the exception is populated
inside the message and then forwarded to an error queue. What *appears* to
be happening is that the message prior to it being processed by the bean is
being forwarded into the queue. If you have any suggestions, please let me
know - Thanks.
Verification Bean
if ( goodOrder )
exchange.getOut().setBody(orderDocument.xmlText());
else {
this.processOrderError(orderDocument, errorLog.toString());
exchange.getOut().setHeader(Exchange.FILE_NAME,
getOrderNumber(orderDocument)+.error.+System.nanoTime()+.xml);
System.out.println(orderDocument.getClarisonicWebOrder().getProcessing().toString());
exchange.getOut().setBody(orderDocument.xmlText());
throw new Exception(Failed Order Verification);
}
// Note: the processOrderMessage() inserts the error message in a defined
area. The subsequent System.out.println() confirms that the error message
is correctly inserted.
My Spring is:
camelContext id=camelContext
xmlns=http://camel.apache.org/schema/spring;
packagemyPackage/package
onException
exceptionjava.lang.Exception/exception
redeliveryPolicy maximumRedeliveries=0 /
handled
constanttrue/constant
/handled
to uri=jms://queue/order-error /
/onException
route
from uri=jms://queue/order-file-processor/
pipeline
bean ref=orderVerifier method=processMessage/
bean ref=orderRuleEnforcer method=processMessage/
bean ref=orderPostprocessor method=processMessage/
to uri=jms://queue/order-data-processor/
/pipeline
/route
/camelContext
The XML that outputs from the order-error queue does not contain the error
message (that I have confirmed in the aforementioned System.out method).
Thanks for your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/OnException-appears-to-roll-back-message-state-Need-help-in-understanding-tp3245784p3245784.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Enabling tracing in production
I think this will be a great improvement for Camel 2.6 or Camel 3.0 - looking up some Camel components from the OSGI regestry by default like a custom tracer, a custom UUID generator, ... At present, we also configure these component in one OSGI bundle and import they in every other bundle. Not really smart... Christian Am 01.11.2010 13:47 schrieb Bengt Rodehav be...@rodehav.com: Thanks Willem - will take a look. BTW, do you have any hints as to whether it's possible to reconfigure a tracer on-the-fly as I described in an earlier post? /Bengt 2010/11/1 Willem Jiang willem.ji...@gmail.com On 10/30/10 4:49 PM, Bengt Rodehav wrote: I have a similar situation but I'm not using Sprin...
Re: Enabling tracing in production
So, back to my original question then... If I declare the following in my Spring context: bean id=camelTracer class=org.apache.camel.processor.interceptor.Tracer / ...and nothing else at all, then tracing is enabled. So how do I then turn off tracing for production mode without having to modify my context? Kind regards, Christopher -- View this message in context: http://camel.465427.n5.nabble.com/Enabling-tracing-in-production-tp3243013p3245879.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Enabling tracing in production
Hello Christopher! If you configure a Tracer in the Camel context, Camel will set tracing to true. You can configure the enabled property in the Tracer. Camel will only trace messages, if this property is set to true (the default). Hope this answers your question, Christian
Re: Enabling tracing in production
Hi Christian, Thanks for your reply. I was hoping that they'd be a way that I could do it via external configuration. I guess I could create a trace property set from my external properties file and have Spring substitute it. However I was hoping that the -trace option to the Main class would do something useful. So far, I don't understand its relevance. Kind regards, Christopher -- View this message in context: http://camel.465427.n5.nabble.com/Enabling-tracing-in-production-tp3243013p3245917.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: how to handle exceptions thrown by camel:choice
The easiest solution could be to catch your exception and return false (I assume you throw an exception if the address string is not well formed for you and in fact invalid). However, where is your 'onException' definition? May be this link is helpful for you: http://camel.apache.org/exception-clause.html (look for Using handeld with Spring DSL) Christian
Re: OnException appears to roll back message state - Need help in understanding
The Camel error handler is covered in chapter 5 in the Camel book if
you want to get to the bottom of understanding it.
Also there is documentation at Camel web site
http://camel.apache.org/error-handling-in-camel.html
The Camel error handler will snapshot the message before its being
processed. And in case the processing failed, it will use the snapshot
message when handling the error. So its correct behavior.
In the JBI/ServiceMix world you can use fault messages instead of exceptions.
getOut().setFault(true);
And then if you still want Camel onException to handle the fault
messages you need to enable this using
.handleFault() in the Camel route
On Mon, Nov 1, 2010 at 10:37 PM, paul botta paul_bo...@hotmail.com wrote:
Hi - I am need of some help in understanding more about exception handling.
I am using Camel 2.2 inside of Servicemix 3.3.2 (along with XMLBeans and
Spring).
What I need to happen is that the nature of the exception is populated
inside the message and then forwarded to an error queue. What *appears* to
be happening is that the message prior to it being processed by the bean is
being forwarded into the queue. If you have any suggestions, please let me
know - Thanks.
Verification Bean
if ( goodOrder )
exchange.getOut().setBody(orderDocument.xmlText());
else {
this.processOrderError(orderDocument, errorLog.toString());
exchange.getOut().setHeader(Exchange.FILE_NAME,
getOrderNumber(orderDocument)+.error.+System.nanoTime()+.xml);
System.out.println(orderDocument.getClarisonicWebOrder().getProcessing().toString());
exchange.getOut().setBody(orderDocument.xmlText());
throw new Exception(Failed Order Verification);
}
// Note: the processOrderMessage() inserts the error message in a defined
area. The subsequent System.out.println() confirms that the error message
is correctly inserted.
My Spring is:
camelContext id=camelContext
xmlns=http://camel.apache.org/schema/spring;
packagemyPackage/package
onException
exceptionjava.lang.Exception/exception
redeliveryPolicy maximumRedeliveries=0 /
handled
constanttrue/constant
/handled
to uri=jms://queue/order-error /
/onException
route
from uri=jms://queue/order-file-processor/
pipeline
bean ref=orderVerifier method=processMessage/
bean ref=orderRuleEnforcer method=processMessage/
bean ref=orderPostprocessor method=processMessage/
to uri=jms://queue/order-data-processor/
/pipeline
/route
/camelContext
The XML that outputs from the order-error queue does not contain the error
message (that I have confirmed in the aforementioned System.out method).
Thanks for your help.
--
View this message in context:
http://camel.465427.n5.nabble.com/OnException-appears-to-roll-back-message-state-Need-help-in-understanding-tp3245784p3245784.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/
Re: unit testing Spring XML route
On Mon, Nov 1, 2010 at 9:44 PM, Mark Webb elihusma...@gmail.com wrote: Figured it out using the page http://camel.apache.org/testing.html and section Spring Test with XML Config Example. The Camel in Action book covers testing in chapter 6 which is a full chapter devoted to testing with Camel. On Mon, Nov 1, 2010 at 4:16 PM, Mark Webb elihusma...@gmail.com wrote: I have a route defined in XML that I want to unit test. Is there a way to do this? I have found CamelSpringTestSupport, but I am not sure that is what I want. When I run a unit test that extends CamelSpringTestSupport I get the following stack trace. org.apache.camel.CamelExecutionException: Exception occurred during execution on the exchange: Exchange[Message: HELLO WORLD] at org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1156) at org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:456) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:441) at org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:437) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:125) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:341) at com.x.y.z.RecipientXmlTest.testTest(RecipientXmlTest.java:33) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at org.apache.camel.test.TestSupport.runBare(TestSupport.java:65) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: org.apache.camel.CamelExchangeException: No consumers available on endpoint: Endpoint[direct://start]. Exchange[Message: HELLO WORLD] at org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:56) at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:99) at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:91) at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85) at org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:333) at org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:208) at org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:303) at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:154) at org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110) at org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:123) ... 22 more -- 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/
