What is recommended way of running many route sets in one application?

of camel contexts and more? Perhaps there are some other options I do not see? Regards, Vladimir Okhotnikov -- View this message in context: http://www.nabble.com/What-is-recommended-way-of-running-many-route-sets-in-one-application--tp25892016p25892016.html Sent from the Camel - Users mailing

Re: File component blocked by existing files

if I somehow made you think I'm feeling different. I just truly believe that infinite waits by default should be ruthlessly eliminated, and doing this will benefit the Camel and its users a great deal. Claus Ibsen-2 wrote: On Mon, Oct 12, 2009 at 10:15 AM, Vladimir Okhotnikov vokhotni

Re: File component blocked by existing files

:56 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Mon, Oct 12, 2009 at 12:27 PM, Vladimir Okhotnikov vokhotni...@gmail.com wrote: Sorry for the poor English - I know about the timeout option now - I saw it immediately AFTER I found the reason. I obviously saw the option before, among others

Re: File component blocked by existing files

this? I will get time next week to take a peak, but would appreciate if you had time to track down more details where the problem may lie. BTW Which OS do you use? On Thu, Oct 8, 2009 at 9:41 PM, Vladimir Okhotnikov vokhotni...@gmail.com wrote: Sorry, Camel 2.0 release 3 routes like

Re: File component blocked by existing files

this? I will get time next week to take a peak, but would appreciate if you had time to track down more details where the problem may lie. BTW Which OS do you use? On Thu, Oct 8, 2009 at 9:41 PM, Vladimir Okhotnikov vokhotni...@gmail.com wrote: Sorry, Camel 2.0 release 3 routes like

File component blocked by existing files

Hi I'm observing quite a strange behavior at the moment. In my app, I have several routes which all start by reading files in the same directory, deleting them after processing. Obviously, each rule uses its own include pattern to process separate subset of files. Now, the problem is that if

Re: File component blocked by existing files

of Camel you are using. And post how you route is configured. On Thu, Oct 8, 2009 at 4:57 PM, Vladimir Okhotnikov vokhotni...@gmail.com wrote: Hi I'm observing quite a strange behavior at the moment. In my app, I have several routes which all start by reading files in the same directory

Re: Zip format problem

though. I think a general solution could be to somehow block the second route while the first route is active. I have no idea though if this can be done with camel. Any ideas? Greetings Christian Vladimir Okhotnikov schrieb: After having slept on it, I think that since you will have

Re: Zip format problem

Actually, not even multicast - just something like uncompress(Zip).to(file://tempDir).body(header(CamelFileName)).aggregate().sort().process(MoveFilesProcessor); Vladimir Okhotnikov wrote: First, you can wire tap (multicast) between uncompress and to(file://tempDir), extract the file names

Re: Zip format problem

I'd rather prefer git than bzr (at least have some limited experience with git). Mercurial is not an option I assume? :-) Christian Grobmeier wrote: I hoped the sandbox was open to other apache committers. However, we'll use GIT or Bazaar for preparing the patch then You can also have

Re: Zip format problem

Will do tomorrow (need to print it out and visit a post office to send it) Christian Grobmeier wrote: Btw, Vladimir can you please sign an ICLA? http://www.apache.org/licenses/icla.txt Thanks -- View this message in context:

Re: Zip format problem

it is possible to reorder processing results before aggregation instead. What do you think? Christian Schneider wrote: Vladimir Okhotnikov schrieb: Christian Schneider wrote: Btw. In our scenario we had the requirement that the files from the zip had to be processed in a certain order

Re: Zip format problem

This would work nice for tar.gz, but not so nice for zip and other formats which tend to combine aggregation and compression in one operation. The main question is, what exactly should do split(Zip) and what decompress(Zip) in your scenario? Christian Schneider wrote: How about using

Re: Zip format problem

Christian Schneider wrote: Hmm, I think you are right as the Zip API is not separate it makes sense to use only one DSL function. The question is then of course how would you name it? Would you rather name the operation split(Zip) or decompress(Zip)? If the operation was named

Re: Zip format problem

Schneider wrote: Vladimir Okhotnikov schrieb: The approach seems okay. The only thing that bothers me is that I'm still not sure the split/aggregate behavior is specific to compression, and will not be useful for other data formats. split and aggregate are already present in the DSL