Camel Component: File - 6.3

Talend ESB Mediation Developer Guide

Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Open Studio for ESB
Talend Real-Time Big Data Platform
Design and Development
Talend ESB

The File component provides access to file systems, allowing files to be processed by any other Camel Components or messages from other components to be saved to disk.

URI format




where directoryName represents the underlying file directory.

You can append query options to the URI in the following format, ?option=value&option=value&...


Camel supports only endpoints configured with a starting directory. So the directoryName must be a directory. If you want to consume a single file only, you can use the fileName option, e.g. by setting fileName=thefilename. Also, the starting directory must not contain dynamic expressions with ${ } placeholders. Again use the fileName option to specify the dynamic part of the filename.


You need to avoid reading files currently being written by another application. Beware the JDK File IO API is somewhat limited in detecting whether another application is currently writing or copying a file. The implementation semantics can also vary, depending on the OS platform. This could lead to the situation where Camel thinks the file is not locked by another process and starts consuming it. You may need to check how this is implemented for your specific environment.

If needed, to assist you with this issue, Camel provides different readLock options and a doneFileName option that you can use. See also the section Consuming files from folders where others drop files directly.

URI Options



Default Value




Automatically create missing directories in the file's pathname. For the file consumer, that means creating the starting directory. For the file producer, it means creating the directory the files should be written to.



Write buffer, sized in bytes.



Use Expression such as File Language to dynamically set the filename. For consumers, it is used as a filename filter. For producers, it is used to evaluate the filename to write. If an expression is set, it takes precedence over the CamelFileName header. ( Note: The header itself can also be an Expression).

The expression options support both String and Expression types. If the expression is a String type, it is always evaluated using the File Language.

If the expression is an Expression type, the specified Expression type is used; this allows you, for instance, to use OGNL expressions. For the consumer, you can use it to filter filenames, so you can for instance consume today's file using the File Language syntax: mydata-${date:now:yyyyMMdd}.txt. Starting with Camel 2.11, the producers support the CamelOverruleFileName header which will take precedence over any existing CamelFileName header. CamelOverruleFileName is used only once, and helps avoid temporarily storing a CamelFileName and needing to restore it afterwards.



Flatten is used to flatten the file name path to strip any leading paths, so it is purely the file name. This allows you to consume recursively into sub-directories. However, for example, if you write the files to another directory they will be written in a (flat) single directory.

Setting this to true on the producer ensures that any file name received in CamelFileName header will be stripped of any leading paths.



This option is used to specify the encoding of the file, and camel will set the Exchange property with Exchange.CHARSET_NAME with the value of this option. You can use this on the consumer, to specify the encodings of the files, which allow Camel to know the charset it should load the file content in case the file content is being accessed. Likewise when writing a file, you can use this option to specify which charset to write the file as well.

copyAndDelete OnRenameFail


Whether to fallback and do a copy and delete file, in case the file could not be renamed directly. This option is not available for the [FTP|FTP2] component.



Perform rename operations using a copy and delete strategy. This is primarily used in environments where the regular rename operation is unreliable (e.g. across different file systems or networks). This option takes precedence over the copyAndDeleteOnRenameFail parameter that will automatically fall back to the copy and delete strategy, but only after additional delays.



Default Value




Milliseconds before polling the file or directory starts.



Milliseconds before the next poll of the file or directory.



Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details.

runLoggingLevelTRACEThe consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that.



if it is consuming a directory, it will look for files in all the sub-directories as well.



If true, the file will be deleted after it is processed



If true, the file is not moved or deleted in any way. This option is good for readonly data, or for ETL type requirements. If noop=true, Camel will set idempotent=true as well, to avoid consuming the same files over and over again.



If a file is to be moved before processing, use Expression such as File Language to dynamically specify the target directory name. For example to move in-progress files into the order directory set this value to order.



If a file is to be moved after processing, use Expression such as File Language to dynamically set the target directory name. To move files into a .done subdirectory just enter .done.



Expression (such as File Language) used to dynamically set a different target directory when moving files in case of processing (configured via move setting defined above) failed. For example, to move files into a .error subdirectory use: .error. Note: When moving the files to the "fail" location Camel will handle the error and will not pick up the file again.



Is used to include files, if filename matches the regex pattern.



Is used to exclude files, if filename matches the regex pattern.

antIncludenullAnt style filter inclusion, for example {{antInclude=**/*.txt}}. Multiple inclusions may be specified in comma-delimited format.
antExcludenullAnt style filter exclusion. If both antInclude and antExclude the latter takes precedence. Multiple exclusions may be specified in comma-delimited format.
antFilter-CaseSensitivetrueStarting with Camel 2.11, whether Ant filters are case sensitive or not.



Option to use the Idempotent Consumer EIP pattern to let Camel skip already processed files. This will by default use a memory based LRUCache that holds 1000 entries. If noop=true then idempotent will be enabled as well to avoid consuming the same files over and over again.



Starting with Camel 2.11, use of a custom idempotent key. By default the absolute path of the file will be used. Camel's File Language can be used to specify the file name and size: idempotentKey=${file:name}-${file:size}.



Pluggable repository as a org.apache.camel. processor.idempotent.MessageIdRepository class. This will by default use MemoryMessageIdRepository if none is specified and idempotent is true.



A pluggable in-progress repository org.apache.camel.spi. IdempotentRepository. The in-progress repository is used to account the current in-progress files being consumed. By default a memory based repository is used.



Pluggable filter as a org.apache.camel.component.file. GenericFileFilter class. This will skip files if filter returns false in its accept() method.



Pluggable sorter as a java.util.Comparator <org.apache.camel.component.file.GenericFile> class.



Built-in sort using the File Language. Supports nested sorts, so you can have a sort by file name and as a second group sort by modified date. See sorting section below for details.



Used by consumer, to only poll the files if it has exclusive read-lock on the file (that is, the file is not in-progress or being written). Camel will wait until the file lock is granted. This option provides the build in strategies:

markerFile Camel creates a marker file (fileName.camelLock) and then holds a lock on it. This option is *not* available for the FTP component.

changed is using file length/modification timestamp to detect whether the file is currently being copied or not. This will at least use 1 sec. to determine this, so this option cannot consume files as fast as the others, but can be more reliable as the JDK IO API cannot always determine whether a file is currently being used by another process. The option readLockCheckInterval can be used to set the check frequency. Note the FTP option fastExistsCheck can be enabled to speed up this readLock strategy, if the FTP server supports the LIST operation with a full file name (some servers may not). not avail for the FTP component.

fileLock is for using java.nio.channels.FileLock. This option is not available for the FTP component. This approach should be avoided when accessing a remote file system via a mount/share unless that file system supports distributed file locks.

rename is for using a try to rename the file as a test if we can get exclusive read-lock.

none is for no read locks at all. Note the read locks changed, fileLock and rename will also use a markerFile as well, to ensure not picking up files that may be in process by another Camel consumer running on another node (eg cluster). This is supported only by the file component (not the ftp component).



Optional timeout in milliseconds for the read-lock, if supported by the read-lock. If the read-lock could not be granted and the timeout triggered, then Camel will skip the file. At next poll Camel, will try the file again, and this time maybe the read-lock could be granted. Use a value of 0 or lower to indicate forever. Currently fileLock, changed and rename support the timeout. Note: for the FTP component the default value is 20000.



Interval in milliseconds for the read-lock, if supported by the read lock. This interval is used for sleeping between attempts to acquire the read lock. For example when using the changed read lock, you can set a higher interval period to cater for slow writes . The default of 1 sec. may be too fast if the producer is very slow writing the file.



This option applied only for readLock=changed. This option allows you to configure a minimum file length. By default Camel expects the file to contain data, and thus the default value is 1. You can set this option to zero to allow consuming zero-length files.



Starting with Camel 2.12: Logging level used when a read lock could not be acquired. By default a WARN is logged. You can change this level, for example to OFF to not have any logging. This option is only applicable for readLock of types: changed, fileLock, rename.



Similar to startingDirectoryMustExist but this applies during polling recursive sub-directories.



If provided, Camel will only consume files if a done file exists. This option configures what file name to use. Either you can specify a fixed name, or you can use dynamic placeholders. The done file is always expected in the same folder as the original file. See using done file and writing done file sections for examples.



Pluggable read-lock as a org.apache.camel.component.file. GenericFileExclusiveReadLockStrategy implementation.



An integer that defines the maximum number of messages to gather per poll. By default, no maximum is set. It can be used to set a limit of, for example, 1000 to avoid having the server read thousands of files as it starts up. Set a value of 0 or negative to disable it. You can use the eagerMaxMessagesPerPoll option and set this to false to allow to scan all files first and then sort afterwards.



Allows for controlling whether the limit from maxMessagesPerPoll is eager or not. If eager then the limit is during the scanning of files. Whereas false would scan all files, and then perform sorting. Setting this option to false allows to sort all files first, and then limit the poll. Note that this requires a higher memory usage as all file details are in memory to perform the sorting.

minDepth0The minimum depth to start processing when recursively processing a directory. Using minDepth=1 means the base directory. Using minDepth=2 means the first sub directory.
maxDepthInteger. MAX_VALUEThe maximum depth to traverse when recursively processing a directory.



A pluggable org.apache.camel.component.file. GenericFileProcessStrategy allowing you to implement your own readLock option or similar. Can also be used when special conditions must be met before a file can be consumed, such as a special ready file exists. If this option is set then the readLock option does not apply.



whether the starting directory must exist. Keep in mind that the autoCreate option is default enabled, which means the starting directory is normally auto created if it doesn't exist. You can disable autoCreate and enable this to ensure the starting directory must exist. It will then throw an exception if the directory doesn't exist.

pollStrategynullA pluggable org.apache.camel.spi. PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation *before* an Exchange has been created and routed in Camel. In other words the error occurred while the polling was gathering information, for instance access to a file network failed so Camel cannot access it to scan for files. The default implementation will log the caused exception at WARN level and ignore it.
sendEmpty-MessageWhenIdlefalseIf the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead.
consumer.bridge-ErrorHandlerfalseAllows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while trying to pickup files, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that by default will be logged at WARN/ERROR level and ignored.
scheduled-ExecutorServicenullAllows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. This option allows you to share a thread pool among multiple file consumers.
schedulernull Camel 2.12: To use a custom scheduler to trigger the consumer to run. See more details at Polling Consumer, for example there is a Quartz2, and Spring based scheduler that supports CRON expressions.
backoffMultiplier0 Camel 2.12: To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. See more details at Polling Consumer.
backoffIdleThreshold0 Camel 2.12: The number of subsequent idle polls that should happen before the backoffMultipler should kick-in.
backoffErrorThreshold0 Camel 2.12: The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in.

Default behavior for file consumer

  • By default the file is locked for the duration of the processing.

  • After the route has completed, files are moved into the .camel subdirectory, so that they appear to be deleted.

  • The File Consumer will always skip any file whose name starts with a dot, such as ., .camel, .m2 or .groovy.

  • Only files (not directories) are matched for valid filename, if options such as: include or exclude are used.



Default Value




What to do if a file already exists with the same name. The following values can be specified: Override, Append, Fail, Ignore, Move, and TryRename (Camel 2.11.1).

  • Override, which is the default, replaces the existing file.

  • Append adds content to the existing file.

  • Fail throws a GenericFileOperation-Exception, indicating that there is already an existing file.

  • Ignore silently ignores the problem and does not override the existing file, but assumes everything is okay. The Move option will move any existing files, before writing the target file. The corresponding moveExisting option must be configured. The option eagerDeleteTargetFile can be used to control what to do if an moving the file, and there exists already an existing file, otherwise causing the move operation to fail.

  • TryRename (Camel 2.11.1) is only applicable if tempFileName option is in use. This allows to try renaming the file from the temporary name to the actual name, without doing any exists check. This check may be faster on some file systems and especially FTP servers.



This option is used to write the file using a temporary name and then, after the write is complete, rename it to the real name. Can be used to identify files being written and also avoid consumers (not using exclusive read locks) reading in-progress files. Is often used by FTP when uploading big files.



The same as tempPrefix option but offering a more fine grained control on the naming of the temporary filename as it uses the File Language .



Expression used to compute file name to use when fileExist=Move is configured. To move files into a backup subdirectory just enter backup. This option supports only the following File Language tokens: "file:name", "file:name.ext", "file:name.noext", "file:onlyname", "file:onlyname.noext", "file:ext", and "file:parent". Notice the "file:parent" is not supported by the FTP component, as the FTP component can move existing files only to a relative directory based on the current directory.



If enabled, will keep the last modified timestamp from the source file (if any). This will use the Exchange. FILE_LAST_MODIFIED header to located the timestamp. This header can contain either a java.util.Date or long with the timestamp. If the timestamp exists and the option is enabled it will set this timestamp on the written file. Note: This option only applies to the file producer. You cannot use this option with any of the ftp producers.



Whether or not to eagerly delete any existing target file. (This option only applies when you use fileExists=Override and the tempFileName option). You can use this to disable deleting the target file before the temp file is written. For example you may have large files and want the target file to persist while the temp file is being written. Setting eagerDeleteTargetFile to false ensures the target file is only deleted until the very last moment, just before the temp file is being renamed to the target filename. This option is also used to control whether to delete any existing files when fileExist=Move is enabled and an existing file is present. If this option copyAndDeleteOnRenameFailis false, then an exception will be thrown if an existing file existed, if it's true, then the existing file is deleted before the move operation.



If provided, then Camel will write a second done file when the original file has been written. The done file will be empty. This option configures what file name to use. Either you can specify a fixed name. Or you can use dynamic placeholders. The done file will always be written in the same folder as the original file. See writing done file section for examples.



Used to specify if a null body is allowed during file writing. If set to true then an empty file will be created, when set to false, and attempting to send a null body to the file component, a GenericFileWriteException of ""Cannot write null body to file" will be thrown. If the "fileExist" option is set to "Override"", then the file will be truncated, and if set to "append"" the file will remain unchanged.



Starting with Camel 2.10.5/2.11, whether to force syncing writes to the file system. You can turn this off if you do not want this level of guarantee, for example if writing to logs / audit logs etc; this would yield better performance.

Default behavior for file producer

By default it will override any existing file, if one exist with the same name.


Override is the default for the file producer. This is also the default file operation using - and also the default for the FTP library we use in the camel-ftp component.

Move and Delete operations

Any move or delete operation is executed after the routing has completed (post command); so during processing of the Exchange the file is still located in the inbox folder.

Let's illustrate this with an example:


When a file is dropped in the inbox folder, the file consumer notices this and creates a new FileExchange that is routed to the handleOrder bean. The bean then processes the File object. At this point in time the file is still located in the inbox folder. After the bean completes, and thus the route is completed, the file consumer will perform the move operation and move the file to the .done sub-folder.

The move and preMove options is considered as a directory name (though if you use an expression such as File Language, or Simple then the result of the expression evaluation is the file name to be used - eg if you set


then that's using the File Language which we use return the file name to be used), which can be either relative or absolute. If relative, the directory is created as a sub-folder from within the folder where the file was consumed.

By default, Camel will move consumed files to the .camel sub-folder relative to the directory where the file was consumed.

If you want to delete the file after processing, the route should be:


We have introduced a pre move operation to move files before they are processed. This allows you to mark which files have been scanned as they are moved to this sub folder before being processed.


You can combine the pre move and the regular move:


So in this situation, the file is in the inprogress folder when being processed and after it is processed, it is moved to the .done folder.

Fine grained control over Move and PreMove option

The move and preMove option is Expression -based, so we have the full power of the File Language to do advanced configuration of the directory and name pattern. Camel will, in fact, internally convert the directory name you enter into a File Language expression. So, for example, when we enter move=.done Camel will convert this into: ${file:parent}/.done/${file:onlyname}. This only happens if Camel detects that you have not provided a ${ } in the option value. So when you enter a ${ } Camel will not convert it and thus you have full control.

So, if we want to move the file into a backup folder with today's date as the pattern, we can do:


About moveFailed

The moveFailed option allows you to move files that could not be processed successfully to another location such as a error folder of your choice. For example to move the files in an error folder with a timestamp you can use moveFailed=/error/${}-${date:now:yyyyMMddHHmmssSSS}.${file:ext}.

See more examples in File Language

Message Headers

The following headers are supported by this component:

File producer only




Specifies the name of the file to write (relative to the endpoint directory). The name can be a String ; a String with a File Language or Simple expression; or an Expression object. If it is null then Camel will auto-generate a filename based on the message unique ID.


The absolute filepath (path + name) for the output file that was written. This header is set by Camel and its purpose is providing end-users with the name of the file that was written.


Starting with Camel 2.11, this field is used for overruling CamelFileName header and use the value instead (but only once, as the producer will remove this header after writing the file). The value can be only be a String. Notice that if the option fileName has been configured, then this is still being evaluated.

File consumer only




Name of the consumed file as a relative file path with offset from the starting directory configured on the endpoint.


Just the file name (the name with no leading paths).


A boolean option specifying whether the consumed file denotes an absolute path or not. It should normally be false for relative paths. Absolute paths should normally not be used but we added to the move option to allow moving files to absolute paths; it can also be used elsewhere.


The absolute path to the file. For relative files this path holds the relative path instead.


The file path. For relative files this is the starting directory + the relative filename. For absolute files this is the absolute path.


The relative path.


The parent path.


A long value containing the file size.


A long value containing the last modified timestamp of the file. In Camel 2.10.3 and older the type is Date.

Batch Consumer

This component implements the Batch Consumer .

Exchange Properties, file consumer only

As the file consumer is BatchConsumer it supports batching the files it polls. By batching it means that Camel will add some properties to the Exchange so you know the number of files polled, and the current index, in that order.




The total number of files that was polled in this batch.


The current index of the batch. Starts from 0.


A boolean value indicating the last Exchange in the batch. Is only true for the last entry.

This would allow you, for example, to know how many files exist in the batch and use that information to let the Aggregator aggregate that precise number of files.

Common gotchas with folder and filenames

When Camel is producing files (writing files) there are a few gotchas affecting how to set a filename of your choice. By default, Camel will use the message ID as the filename, and since the message ID is normally a unique generated ID, you will end up with filenames such as: ID-MACHINENAME-2443-1211718892437-1-0 . If such a filename is not desired, then you must provide a filename in the CamelFileName message header. The constant, Exchange.FILE_NAME, can also be used.

The sample code below produces files using the message ID as the filename:


To use report.txt as the filename you have to do:

from("direct:report").setHeader(Exchange.FILE_NAME, constant("report.txt"))
   .to( "file:target/reports");

... the same as above, but with CamelFileName :

from("direct:report").setHeader("CamelFileName", constant("report.txt"))
   .to( "file:target/reports");

An example of a syntax where we set the filename on the endpoint with the fileName URI option:


Filename Expression

Filename can be set either using the expression option or as a string-based File Language expression in the CamelFileName header. See the File Language for syntax and samples.

Consuming files from folders where others drop files directly

Warning: there may be difficulties if you consume files from a directory where other applications directly write files. Please look at the different readLock options to see if they can help.

If you are writing files to the folder, then the best approach is to write to another folder and after the write, move the file in the drop folder.

However if you need to write files directly to the drop folder then the option changed could better detect whether a file is currently being written/copied. changed uses a file changed algorithm to see whether the file size or modification changes over a period of time. The other readLock options rely on Java File API which is not always good at detecting file changes. You may also want to look at the doneFileName option, which uses a marker file (done) to signal when a file is done and ready to be consumed.

Using done files

See also section writing done files below.

If you want only to consume files when a done file exists, then you can use the doneFileName option on the endpoint.


This will only consume files from the bar folder, if a file name done exists in the same directory as the target files. For versions prior to 2.9.3, Camel will automatically delete the done file when it is finished consuming the files.

However it's more common to have one done file per target file. This means there is a 1:1 correlation. To do this you must use dynamic placeholders in the doneFileName option. Currently Camel supports the following two dynamic tokens: file:name and file:name.noext which must be enclosed in ${ }. The consumer only supports the static part of the done file name as either prefix or suffix (not both).


In this example only files will be polled if there exists a done file with the name file name .done. For example

  • hello.txt is the file to be consumed

  • hello.txt.done is the associated done file

You can also use a prefix for the done file, such as:

  • hello.txt is the file to be consumed

  • ready-hello.txt is the associated done file

Writing done files

After you have written a file you may want to write an additional done file as a kind of marker, to indicate to others that the file is finished and has been written. To do that you can use the doneFileName option on the file producer endpoint.


This will simply create a file named done in the same directory as the target file.

However it's more common to have one done file per target file. This means there is a 1:1 correlation. To do this you must use dynamic placeholders in the doneFileName option. Currently Camel supports the following two dynamic tokens: file:name and file:name.noext which must be enclosed in ${ }.


This will for example create a file named done-foo.txt if the target file was foo.txt in the same directory as the target file.


This will for example create a file named foo.txt.done if the target file was foo.txt in the same directory as the target file.


This will for example create a file named foo.done if the target file was foo.txt in the same directory as the target file.


Read from a directory and write to another directory


The above will listen on a directory and create a message for each file dropped there. It will copy the contents to the outputdir and delete the file in the inputdir. Using .to("file://outputdir?overruleFile=copy-of-${file:name}") instead will allow you to write to another directory using a dynamic overrule name.

Read from a directory and write to another directory using a overrule dynamic name

Listen on a directory and create a message for each file dropped there. Copy the contents to the outputdir and delete the file in the inputdir.

Reading recursively from a directory and writing to another


Listen on a directory and create a message for each file dropped there. Copy the contents to the outputdir and delete the file in the inputdir. This will scan recursively into sub-directories, and lay out the files in the same directory structure in the outputdir as the inputdir, including any sub-directories.


This will result in the following output layout:

Using flatten

If you want to store the files in the outputdir directory in the same directory, disregarding the source directory layout (for example to flatten out the path), you add the flatten=true option on the file producer side:


This will result in the following output layout:


Reading from a directory and the default move operation

Camel will by default move any processed file into a .camel subdirectory in the directory the file was consumed from.


Affects the layout as follows:





Read from a directory and process the message in java

from("file://inputdir/").process(new Processor() {
   public void process(Exchange exchange) throws Exception {
      Object body = exchange.getIn().getBody();
      // do some business logic with the input body

The body will be a File object that points to the file that was just dropped into the inputdir directory.

Writing to files

Camel is of course also able to write files, that is, produce files. In the sample below we receive some reports on the SEDA queue that we process before the reports are written to a directory.

public void testToFile() throws Exception {
   MockEndpoint mock = getMockEndpoint("mock:result");

   template.sendBody("direct:reports", "This is a great report");


protected JndiRegistry createRegistry() throws Exception {
   // bind our processor in the registry with the given id
   JndiRegistry reg = super.createRegistry();
   reg.bind("processReport", new ProcessReport());
   return reg;

protected RouteBuilder createRouteBuilder() throws Exception {
   return new RouteBuilder() {
      public void configure() throws Exception {
         // the reports from the seda queue are processed by our 
         // processor before they are written to files in the 
         // target/reports directory
            .to("file://target/test-reports", "mock:result");

private class ProcessReport implements Processor {

   public void process(Exchange exchange) throws Exception {
      String body = exchange.getIn().getBody(String.class);
      // do some business logic here
      // set the output to the file

      // set the output filename using java code logic, notice that this 
      // is done by setting a special header property of the out exchange
      exchange.getOut().setHeader(Exchange.FILE_NAME, "report.txt");


Write to subdirectory using Exchange.FILE_NAME

Using a single route, it is possible to write a file to any number of subdirectories. If you have a route setup as such:

   <from uri="bean:myBean"/>
   <to uri="file:/rootDirectory"/>

You can have myBean set the header Exchange.FILE_NAME to values such as:

Exchange.FILE_NAME = hello.txt => /rootDirectory/hello.txt
Exchange.FILE_NAME = foo/bye.txt => /rootDirectory/foo/bye.txt

This allows you to have a single route to write files to multiple destinations.

Writing file through the temporary directory relative to the final destination

Sometime you need to temporarily write the files to some directory relative to the destination directory. Such situation usually happens when some external process with limited filtering capabilities is reading from the directory you are writing to. In the example below files will be written to the /var/myapp/filesInProgress directory and after data transfer is done, they will be atomically moved to the /var/myapp/finalDirectory directory.


Using expression for filenames

In this sample we want to move consumed files to a backup folder using today's date as a sub-folder name:


See File Language for more samples.

Avoiding reading the same file more than once (idempotent consumer)

Camel supports Idempotent Consumer directly within the component so it will skip already processed files. This feature can be enabled by setting the idempotent=true option.


Camel uses the absolute file name as the idempotent key, to detect duplicate files. From Camel 2.11 onwards you can customize this key by using an expression in the idempotentKey option. For example to use both the name and the file size as the key:

   <to uri="bean:processInbox"/>

By default Camel uses a in memory based store for keeping track of consumed files, it uses a least recently used cache holding up to 1000 entries. You can plugin your own implementation of this store by using the idempotentRepository option using the # sign in the value to indicate it is a referring to a bean in the Registry with the specified id .

<!-- Define our store as a plain Spring bean -->
<bean id="myStore" class="com.mycompany.MyIdempotentStore"/>

   <from uri="file://inbox?idempotent=true&amp;idempotentRepository=#myStore"/>
   <to uri="bean:processInbox"/>

Camel will log at DEBUG level if it skips a file because it has been consumed before:

DEBUG FileConsumer is idempotent and the file has been consumed before. 
This will skip this file: target\idempotent\report.txt

Filter using org.apache.camel.component.file.GenericFileFilter

Camel supports pluggable filtering strategies. You can then configure the endpoint with such a filter to skip certain files being processed.

In the sample we have built our own filter that skips files starting with skip in the filename:

public class MyFileFilter implements GenericFileFilter {
   public boolean accept(GenericFile pathname) {
      // we don't accept any files starting with skip in the name
      return !pathname.getFileName().startsWith("skip");

Then we can configure our route using the filter attribute to reference our filter (using # notation) that we have defines in the Spring XML file:

<!-- define our sorter as a plain Spring bean -->
<bean id="myFilter" class="com.mycompany.MyFileSorter"/>

   <from uri="file://inbox?filter=#myFilter"/>
   <to uri="bean:processInbox"/>

Filtering using ANT path matcher


There are also antInclude and antExclude options to make it easy to specify ANT style include/exclude without having to define the filter. See the URI options above for more information.

The ANT path matcher is shipped out-of-the-box in the camel-spring jar. So you need to depend on camel-spring if you are using Maven. The reason is that we leverage Spring's AntPathMatcher to do the matching.

The file paths is matched with the following rules:

  • ? matches one character

  • * matches zero or more characters

  • ** matches zero or more directories in a path

The sample below demonstrates how to use it:

<camelContext xmlns="">
   <template id="camelTemplate"/>

   <!-- use myFilter as filter to allow setting 
         ANT paths for which files to scan for -->
   <endpoint id="myFileEndpoint" uri=

      <from ref="myFileEndpoint"/>
      <to uri="mock:result"/>

<!-- we use the antpath file filter to use Ant paths -->
<!-- for includes and excludes -->
<bean id="myAntFilter" 
   <!-- include and file in the subfolder that has 'day' in the name -->
   <property name="includes" value="**/subfolder/**/*day*"/>
   <!-- exclude all files with 'bad' in name or .xml files. -->
   <!-- Use comma to separate multiple excludes -->
   <property name="excludes" value="**/*bad*,**/*.xml"/>

Sorting using Comparator

Camel supports pluggable sorting strategies. This strategy it to use the built in java.util.Comparator in Java. You can then configure the endpoint with such a comparator and have Camel sort the files before being processed.

In the sample we have built our own comparator that sorts by file name:

public class MyFileSorter implements Comparator<GenericFile> {
    public int compare(GenericFile o1, GenericFile o2) {
        return o1.getFileName().compareToIgnoreCase(o2.getFileName());

Then we can configure our route using the sorter option to reference to our sorter ( mySorter ) we have defined in the Spring XML file:

<!-- Define our sorter as a plain Spring bean -->
   <bean id="mySorter" class="com.mycompany.MyFileSorter"/>

   <from uri="file://inbox?sorter=#mySorter"/>
   <to uri="bean:processInbox"/>


URI options can reference beans using the # syntax. In the Spring DSL route, notice that we can refer to beans in the Registry by prefixing the id with #. So writing sorter=#mySorter, will instruct Camel to go look in the Registry for a bean with the ID, mySorter.

Sorting using sortBy

Camel supports pluggable sorting strategies. This strategy it to use the File Language to configure the sorting. The sortBy option is configured as follows:

sortBy=group 1;group 2;group 3;...

where each group is separated with semi colon. In the simple situations you just use one group, so a simple example could be:


This will sort by file name, you can reverse the order by prefixing reverse: to the group, so the sorting is now Z..A:


As we have the full power of File Language we can use some of the other parameters, so if we want to sort by file size we do:


You can configure to ignore the case, using ignoreCase: for string comparison, so if you want to use file name sorting but to ignore the case then we do:


You can combine ignore case and reverse, however reverse must be specified first:


In the sample below we want to sort by last modified file, so we do:


Then we want to group by name as a second option so files with same modification is sorted by name:


Now there is an issue here, can you spot it? Well the modified timestamp of the file is too fine as it will be in milliseconds, but what if we want to sort by date only and then subgroup by name? Well as we have the true power of File Language we can use the its date command that supports patterns. So this can be solved as:


That is powerful. You can also use reverse per group, so we could reverse the file names:


Using GenericFileProcessStrategy

The option processStrategy can be used to use a custom GenericFileProcessStrategy that allows you to implement your own begin, commit and rollback logic. For instance let's assume a system writes a file in a folder you should consume. But you should not start consuming the file before another ready file have been written as well.

So by implementing our own GenericFileProcessStrategy we can implement this as:

  • In the begin() method we can test whether the special ready file exists. The begin method returns a boolean to indicate if we can consume the file or not.

  • In the abort() special logic can be executed in case the begin operation returned false, for example to cleanup resources, etc.

  • in the commit() method we can move the file and also delete the ready file.