apache-camel

I have a simple camel route I need to modify. The route looks like this: from(source.uri) .unmarshal() .bean(TransformMessageBean.class, "SomeMethod") .to(destination.uri) I want to add another bean method call after the unmarshaling that set's a header value without disrupting the current data flow . Does anyone know of a way to do this? I read that in apache's documentation that a bean's return value is set in the outbound message body. Is there a way to change that to a header? Thanks in advance! Certainly! One of the options available is .setHeader("headerName").method(beanInstance,

This seems like it should be simple, pardon the pun. I'm trying to log a header in camel within a spring DSL route. I've seen the answer for Java DSL but I've been searching in vain for how to make it work in spring DSL. I've tried: <log message="ftping $simple{header.CamelFileName}"/> and also: <log message="ftping ${header.CamelFileName}"/> and several other permutations/variations, but all of them simply log that text verbatim (i.e. they do not substitute the actual header name). What am I missing? update: here's a larger portion of my xml file: <split> <simple>${body}</simple> <setHeader

I have just started learning Apache Camel. I understood the basics of Routes and Components. Now I want to give a try by connecting to Oracle database, reading records from one particular table and write those records to a file using File component. To read from database I assume I need to use JDBC component and give the dataSourceName . However, I couldn't find any info on how to create a dataSource using camel. All info that I found related to this topic uses Spring DSL examples. I don't use Spring and I just need to test this using simple standalone Java application. I am using JDK7u25 with

Apache Camel offers several ways of performing data transforms: its concept of the Transform EIP, custom DataFormats, as well as its allowance for custom Type Converters. I have a situation where I need to do a very complex transform from inside a Camel route. Should I be implementing my own Type Converter, my own DataFormat, or should I implement org.apache.camel.Expression and put all the transform stuff in there: public class MyTransformer implements Expression { @Override public <T> T evaluate(Exchange arg0, Class<T> arg1) { // ... } } I guess I'm confused about where/when it's appropriate

I'm trying to remove some boilerplate from routes in Camel. For example, let's consider the two routes, which are similar and most of their inner stuff could be generated. I've created a component "template", which creates TemplateEndpoint , and modifyed an XML config to use the template component. A custom method TemplateEndpoint.generateRoute (adding route definitions) is being called from StartupListener (defined in TemplateEndpoint.setSuffix ). So while Camel context starting, route definitions appear in the context, but the framework doesn't create route services for them and hence they

Let's say I have a Camel route that looks like this : from("direct:myRoute") .setHeader("someHeader", simple("some header value")) .beanRef("myBean", "beanMethod"); And I have a bean that I cannot change that looks like this : public class MyBean { public void beanMethod(String headerExpected) { // do something with the value here. } } Basically, I want to pass the value of someHeader from myRoute to beanMethod within MyBean . Knowing that beanMethod can accept a String , how can I pass the value of the header someHeader from the route so that it is accepted as a String within beanMethod ? You

I am trying to wrap my head around Apache Camel, which appears to be a lightweight ESB. If I understand Camel/ESBs correctly, then you can think of a Camel Route as a graph of nodes and edges. Each node is an endpoint on the route (can consume/produce messages). Each edge is a route between two different endpoints (1 producer and 1 consumer). Assuming that's correct, I have a practical question: what do best practices dictate about deploying your application's ESB/Camel Route? Should I package it up as its own JAR, or is it worthy of being its own EAR full of EJBs, Web Services and other JARs?