camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <>
Subject Re: Problem with pollEnrich
Date Wed, 07 Nov 2012 20:08:15 GMT

Am 07.11.12 09:28 schrieb "Babak Vahdat" unter

>There's a routing use case currently I'm stuck with which goes as the
>- Download an index file from a FTP server containing the list of (to be
>downloaded) files which're listed in this index file line by line
>- Do some futher processing with the index file being downloaded which is
>not relevant here
>- Download each file being listed inside the index file one after another.
>Any other potential file not being referenced inside the index file should
>be ignored 
>- Do some further processing with each file being downloaded which is not
>relevant here
>The requirement is
>- Make use of Spring DSL
>- *If* possible do not write any single line of java code but make use of
>what Spring DSL can offer
>My first try was:
>from ftp://...fileName=index.txt
>   to file://...
>   ...
>   convertBodyTo String
>   split
>      tokenize ...
>      pollEnrich ftp://...fileName=...${in.body}
>      ...
>   split
>Now there're two problems here:
>According to what the read box says here:
>I can not access anything from the current exchange to tell the pollEnrich
>the file name I want to download.
>And according:
>I can not make use of any other expression to tell the FTP polling
>which file I intend to download.
>I appreciate any hint you could give me.

At the end of the day I gave up using pollEnrich DSL and made use of
ConsumerTemplate wrapped inside a Bean which gets invoked through the Bean
endpoint inside Spring DSL. Just wonder if there's any better way to do

Ah, still completley another story which baffled me also a while:
DefaultPropertiesResolver.prepareLoadedProperties does *trim* a given
value. In my case I had a key/value pair defined inside a properties file


Which of course after trimming became an empty string of the length 0! so
that the split step above using this value did not behave as expected.
IMHO it would be better to log at INFO or WARN level about this trimming
step so people are aware of this. To resolve this I overided the strategy
method as following:

public class MyPropertiesResolver extends DefaultPropertiesResolver {
  protected Properties prepareLoadedProperties(Properties properties) {
  // return the passed properties as is to avoid any value trimming taking
place by default
  return properties;

And then inside the test injected my own resolver:

    protected CamelContext createCamelContext() throws Exception {
   CamelContext camelContext = super.createCamelContext();
   PropertiesComponent propertiesComponent =
camelContext.getComponent("properties", PropertiesComponent.class);
   propertiesComponent.setPropertiesResolver(new MyPropertiesResolver());

   return camelContext;

Hope this can be helpful for others experiencing the same problem.


>View this message in context:
>Sent from the Camel - Users mailing list archive at

View raw message