camel-servlet in a Spring Web MVC app?

Hi, we have an existing fairly mature Spring Web MVC application that runs with an embedded Jetty. The application also implements Spring Security. We have also successfully used some Camel routing within the application (with file and message queue endpoints.) My question: Is it possible to u

problem using recipientList (NoSuchEndpointException: CachedOutputStream$WrappedInputStream)

Hi, I have been trying to use /*recipientList*/ to resolve dynamic target endpoints while using Camel as an HTTP proxy between a client and a server. Everything works fine without /recipientList/ - if I do something like this: @Override public void configure() throws Exception { from(

Re: problem using recipientList (NoSuchEndpointException: CachedOutputStream$WrappedInputStream)

Thank you so much for the quick response, Claus! It works as advertised now! -- View this message in context: http://camel.465427.n5.nabble.com/problem-using-recipientList-NoSuchEndpointException-CachedOutputStream-WrappedInputStream-tp5744249p5744254.html Sent from the Camel - Users mailing l

Camel AWS-SNS: is there a way to add subscriber to topic that is created on the fly?

The doc page for the AWS-SNS Camel component states: "The topic will be created if they don't already exists." Is there a way to specify a subscriber (or a list of subscribers) in the exchange - to be created for the topicARN specified in the endpoint URI? Thanks! -- View this message in con

Disabling coma delimiter in @RecipientList-annotated methods that return String

The Recipient List documentation states: /Notice that the Recipient List can send to multiple Endpoints if the expression returns either a java.util.List, array, java.util.Iteratable or a String. If the returned value is a String the

Having issue with +

Hi, I am using Camel 2.14.2. All my RouteBuilder implementations are @Component annotated Spring beans, auto-wired with processors, error handlers, AggregationStrategy implementation beans, etc. I have been using componentScan to load these Spring beans into Camel context. However, I have one rout

Excluding prototype-scoped @Component route builder from ?

Hi, I am using Camel 2.14.2. All my RouteBuilder implementations are @Component annotated Spring beans, auto-wired with processors, error handlers, AggregationStrategy implementation beans, etc. I have been using *contextScan* to load these Spring beans into Camel context. However, I have one rout

Re: Excluding prototype-scoped @Component route builder from ?

Claus, thank you for your response. Removing spaces didn't help (and, frankly, I'd be surprised if it did.) I did the following: http://camel.apache.org/schema/spring";> com.myco.something.route.MyExcludedRouteBuilder Same error. -- View this mes

Re: Excluding prototype-scoped @Component route builder from ?

OK, thanks for looking into this. In the meantime, I suppose I'd have to remove @Component annotation from my route builders, define them in the Spring XML file and then define the routeBuilders with the references to them. That's inconsistent with the rest of my Spring components, but that certain

DSL to dynamically enable/disable parallelProcessing?

Hi, I am using a splitter to read a file. The definition looks something like this: split(). tokenize(System.lineSeparator(), readerConfig.getLinesPerChunk()). streaming(). parallelProcessing(). bean(myProces

Re: DSL to dynamically enable/disable parallelProcessing?

Thanks, Claus. So, this will be available in 2.16.x. In the meantime, do you mind providing a working example of how to use conditional DSL? I have tried something like this, which didn't work: split(). tokenize(System.lineSeparator(), readerConfig.getLinesPerChunk()).

splitter().tokenize(...) does not recognize new lines in file uploaded using Spring MVC MultipartFile

I have a route configuration that uses splitter().tokenize(...): from(FILE_SPLITTER_ENDPOINT).routeId("fileSplitterRoute"). split(). tokenize(System.lineSeparator(), config.getLinesPerChunk()). streaming(). // enable streaming vs. reading all in

splitter().tokenize(...) does not recognize new lines in file uploaded using Spring MVC MultipartFile

I have a route configuration that uses splitter().tokenize(...): from(FILE_SPLITTER_ENDPOINT).routeId("fileSplitterRoute"). split(). tokenize(System.lineSeparator(), config.getLinesPerChunk()). streaming(). // enable streaming vs. reading all in

Re: splitter().tokenize(...) does not recognize new lines in file uploaded using Spring MVC MultipartFile

That's what baffles me: the file is created on the same system, on the same server. In this case it is Mac OS. This even happens if the Camel route runs within the same Spring MVC application that uploads the file! I have tried using the explicit "\n" for the line separator in the tokenizer, got s

Re: How do I maintain custom ojbect in the camel context scope?

You could always have an application-global object (an instance that lives in your application context) injected into your Camel processor classes. Assuming you implement your exchange processing logic in endpoint-specific POJO "processors", you could wire/inject a reference to that bean into each

Re: splitter().tokenize(...) does not recognize new lines in file uploaded using Spring MVC MultipartFile

Well, it turns out that the uploaded files had ONLY the '\r' (x0D) character for the "new line". I was too blind to see - assuming that it could only be either '\n' (UNIX) or "\r\n" (MS Windows.) So, I was staring at 'x0D' not even questioning the fact that it represented '\n', while it is, of cour

split().tokenize() w/regex-type token arg and grouping DOESN'T GROUP split items

If a regular expression used in the /tokenize(...)/ method when splitting a file payload by lines, the "group" method argument is ignored and no lines are grouped. For example, consider the following code to split the file into exchanges with 100 lines per exchange. The regular expression (the fir

Re: split().tokenize() w/regex-type token arg and grouping DOESN'T GROUP split items

Just checked the Camel source code: /** * Evaluates a token expression on the message body * * @param token the token * @param regex whether the token is a regular expression or not * @param group to group by the given number * @return the builder to continue proc

Re: split().tokenize() w/regex-type token arg and grouping DOESN'T GROUP split items

Thank you, Claus! -- View this message in context: http://camel.465427.n5.nabble.com/split-tokenize-w-regex-type-token-arg-and-grouping-DOESN-T-GROUP-split-items-tp5773166p5773186.html Sent from the Camel - Users mailing list archive at Nabble.com.

correct way to provide regex in TokenizerExpression?

What is the correct way to supply the regular expression in TokenizerExpression? Per Claus's advise, I have tried the following to tokenize a file by lines while grouping lines - using a regex to support more than one type of line separators: TokenizerExpression tokenizerExpression = new

Re: correct way to provide regex in TokenizerExpression?

I have played with it some more, and it seems clear that the tokenizer does NOT support regular expressions as advertised. Moreover, it seems that there is no way to write a system-agnostic file splitter that groups lines! I may be wrong, and if so, can anyone PLEASE show me the proper way to do it

Re: correct way to provide regex in TokenizerExpression?

Forgot to mention: when I inspect the exchange that is expected to contain the grouped N lines from the file that is being processed, I see that Camel inserts the actual regex string I provided to the tokenizer between the lines from the file! The exchange message looks like this: "[Message: linef

Re: correct way to provide regex in TokenizerExpression?

Ok, here's the workaround I have implemented to go past the above issue... Some MyConstants.java file: public static final String SYSTEM_AGNOSTIC_NEWLINE_REGEX = "\r|\r\n|\n"; Splitter route configuration in a RouteBuilder implementation: TokenizerExpression tokenizerExpression = new

Re: correct way to provide regex in TokenizerExpression?

Hi Claus, thank you for responding. The problem we are seeing currently is that, if we provide a regex to the tokenizer to detect token delimiters, the tokenizer inserts that expression literal into the payload itself - while replacing the actual delimiters matched by the regex. I think you will ag