You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by ac...@apache.org on 2016/11/07 12:00:57 UTC
camel git commit: Full Build with fresh tooling
Repository: camel
Updated Branches:
refs/heads/master 782b04c55 -> 10c2e35f2
Full Build with fresh tooling
Project: http://git-wip-us.apache.org/repos/asf/camel/repo
Commit: http://git-wip-us.apache.org/repos/asf/camel/commit/10c2e35f
Tree: http://git-wip-us.apache.org/repos/asf/camel/tree/10c2e35f
Diff: http://git-wip-us.apache.org/repos/asf/camel/diff/10c2e35f
Branch: refs/heads/master
Commit: 10c2e35f24d65b1c138937df65e6735f548b5bfd
Parents: 782b04c
Author: Andrea Cosentino <an...@gmail.com>
Authored: Mon Nov 7 12:59:53 2016 +0100
Committer: Andrea Cosentino <an...@gmail.com>
Committed: Mon Nov 7 12:59:53 2016 +0100
----------------------------------------------------------------------
camel-core/src/main/docs/file-component.adoc | 2 +-
components-starter/camel-aws-starter/pom.xml | 4 +++
.../camel-facebook-starter/pom.xml | 2 ++
.../camel-hystrix-starter/pom.xml | 4 +++
components-starter/camel-jolt-starter/pom.xml | 2 ++
.../camel-kubernetes-starter/pom.xml | 2 ++
.../camel-ftp/src/main/docs/ftp-component.adoc | 2 +-
.../camel-ftp/src/main/docs/ftps-component.adoc | 2 +-
.../camel-ftp/src/main/docs/sftp-component.adoc | 2 +-
.../camel-spring-boot-dependencies/pom.xml | 38 ++++++++++----------
10 files changed, 37 insertions(+), 23 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/camel-core/src/main/docs/file-component.adoc
----------------------------------------------------------------------
diff --git a/camel-core/src/main/docs/file-component.adoc b/camel-core/src/main/docs/file-component.adoc
index 26b38aa..25a6726 100644
--- a/camel-core/src/main/docs/file-component.adoc
+++ b/camel-core/src/main/docs/file-component.adoc
@@ -127,7 +127,7 @@ The File component supports 81 endpoint options which are listed below:
| minDepth | filter | | int | The 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.
| move | filter | | String | Expression (such as Simple Language) used to dynamically set the filename when moving it after processing. To move files into a .done subdirectory just enter .done.
| exclusiveReadLockStrategy | lock | | GenericFileExclusiveReadLockStrategy<T> | Pluggable read-lock as a org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy implementation.
-| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mode where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
+| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-changed - (only for file component) idempotent-changed is for using a idempotentRepository and changed as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-rename - (only for file component) idempotent-rename is for using a idempotentRepository and rename as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mo
de where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
| readLockCheckInterval | lock | 1000 | long | Interval in millis 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. Notice: For FTP the default readLockCheckInterval is 5000. The readLockTimeout value must be higher than readLockCheckInterval but a rule of thumb is to have a timeout that is at least 2 or more times higher than the readLockCheckInterval. This is needed to ensure that amble time is allowed for the read lock process to try to grab the lock before the timeout was hit.
| readLockDeleteOrphanLockFiles | lock | true | boolean | Whether or not read lock with marker files should upon startup delete any orphan read lock files which may have been left on the file system if Camel was not properly shutdown (such as a JVM crash). If turning this option to false then any orphaned lock file will cause Camel to not attempt to pickup that file this could also be due another node is concurrently reading files from the same shared directory.
| readLockLoggingLevel | lock | WARN | LoggingLevel | 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.
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components-starter/camel-aws-starter/pom.xml
----------------------------------------------------------------------
diff --git a/components-starter/camel-aws-starter/pom.xml b/components-starter/camel-aws-starter/pom.xml
index 0b14ca2..7434cfd 100644
--- a/components-starter/camel-aws-starter/pom.xml
+++ b/components-starter/camel-aws-starter/pom.xml
@@ -36,13 +36,16 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-aws</artifactId>
<version>${project.version}</version>
+ <!--START OF GENERATED CODE-->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
+ <!--END OF GENERATED CODE-->
</dependency>
+ <!--START OF GENERATED CODE-->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core-starter</artifactId>
@@ -51,5 +54,6 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
</dependency>
+ <!--END OF GENERATED CODE-->
</dependencies>
</project>
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components-starter/camel-facebook-starter/pom.xml
----------------------------------------------------------------------
diff --git a/components-starter/camel-facebook-starter/pom.xml b/components-starter/camel-facebook-starter/pom.xml
index 3d90746..5e224d5 100644
--- a/components-starter/camel-facebook-starter/pom.xml
+++ b/components-starter/camel-facebook-starter/pom.xml
@@ -37,6 +37,7 @@
<artifactId>camel-facebook</artifactId>
<version>${project.version}</version>
</dependency>
+ <!--START OF GENERATED CODE-->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core-starter</artifactId>
@@ -45,5 +46,6 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
</dependency>
+ <!--END OF GENERATED CODE-->
</dependencies>
</project>
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components-starter/camel-hystrix-starter/pom.xml
----------------------------------------------------------------------
diff --git a/components-starter/camel-hystrix-starter/pom.xml b/components-starter/camel-hystrix-starter/pom.xml
index a4c6b13..8d47976 100644
--- a/components-starter/camel-hystrix-starter/pom.xml
+++ b/components-starter/camel-hystrix-starter/pom.xml
@@ -36,13 +36,16 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-hystrix</artifactId>
<version>${project.version}</version>
+ <!--START OF GENERATED CODE-->
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
+ <!--END OF GENERATED CODE-->
</dependency>
+ <!--START OF GENERATED CODE-->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core-starter</artifactId>
@@ -51,5 +54,6 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
</dependency>
+ <!--END OF GENERATED CODE-->
</dependencies>
</project>
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components-starter/camel-jolt-starter/pom.xml
----------------------------------------------------------------------
diff --git a/components-starter/camel-jolt-starter/pom.xml b/components-starter/camel-jolt-starter/pom.xml
index ab31412..60aaf54 100644
--- a/components-starter/camel-jolt-starter/pom.xml
+++ b/components-starter/camel-jolt-starter/pom.xml
@@ -37,6 +37,7 @@
<artifactId>camel-jolt</artifactId>
<version>${project.version}</version>
</dependency>
+ <!--START OF GENERATED CODE-->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core-starter</artifactId>
@@ -45,5 +46,6 @@
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
</dependency>
+ <!--END OF GENERATED CODE-->
</dependencies>
</project>
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components-starter/camel-kubernetes-starter/pom.xml
----------------------------------------------------------------------
diff --git a/components-starter/camel-kubernetes-starter/pom.xml b/components-starter/camel-kubernetes-starter/pom.xml
index f263a23..a117324 100644
--- a/components-starter/camel-kubernetes-starter/pom.xml
+++ b/components-starter/camel-kubernetes-starter/pom.xml
@@ -37,6 +37,7 @@
<artifactId>camel-kubernetes</artifactId>
<version>${project.version}</version>
</dependency>
+ <!--START OF GENERATED CODE-->
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core-starter</artifactId>
@@ -49,5 +50,6 @@
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
</dependency>
+ <!--END OF GENERATED CODE-->
</dependencies>
</project>
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components/camel-ftp/src/main/docs/ftp-component.adoc
----------------------------------------------------------------------
diff --git a/components/camel-ftp/src/main/docs/ftp-component.adoc b/components/camel-ftp/src/main/docs/ftp-component.adoc
index ee9104c..79e046b 100644
--- a/components/camel-ftp/src/main/docs/ftp-component.adoc
+++ b/components/camel-ftp/src/main/docs/ftp-component.adoc
@@ -201,7 +201,7 @@ The FTP component supports 105 endpoint options which are listed below:
| minDepth | filter | | int | The 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.
| move | filter | | String | Expression (such as Simple Language) used to dynamically set the filename when moving it after processing. To move files into a .done subdirectory just enter .done.
| exclusiveReadLockStrategy | lock | | GenericFileExclusiveReadLockStrategy<T> | Pluggable read-lock as a org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy implementation.
-| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mode where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
+| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-changed - (only for file component) idempotent-changed is for using a idempotentRepository and changed as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-rename - (only for file component) idempotent-rename is for using a idempotentRepository and rename as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mo
de where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
| readLockCheckInterval | lock | 1000 | long | Interval in millis 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. Notice: For FTP the default readLockCheckInterval is 5000. The readLockTimeout value must be higher than readLockCheckInterval but a rule of thumb is to have a timeout that is at least 2 or more times higher than the readLockCheckInterval. This is needed to ensure that amble time is allowed for the read lock process to try to grab the lock before the timeout was hit.
| readLockDeleteOrphanLockFiles | lock | true | boolean | Whether or not read lock with marker files should upon startup delete any orphan read lock files which may have been left on the file system if Camel was not properly shutdown (such as a JVM crash). If turning this option to false then any orphaned lock file will cause Camel to not attempt to pickup that file this could also be due another node is concurrently reading files from the same shared directory.
| readLockLoggingLevel | lock | WARN | LoggingLevel | 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.
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components/camel-ftp/src/main/docs/ftps-component.adoc
----------------------------------------------------------------------
diff --git a/components/camel-ftp/src/main/docs/ftps-component.adoc b/components/camel-ftp/src/main/docs/ftps-component.adoc
index 333b09a..53eff1d 100644
--- a/components/camel-ftp/src/main/docs/ftps-component.adoc
+++ b/components/camel-ftp/src/main/docs/ftps-component.adoc
@@ -114,7 +114,7 @@ The FTPS component supports 113 endpoint options which are listed below:
| minDepth | filter | | int | The 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.
| move | filter | | String | Expression (such as Simple Language) used to dynamically set the filename when moving it after processing. To move files into a .done subdirectory just enter .done.
| exclusiveReadLockStrategy | lock | | GenericFileExclusiveReadLockStrategy<T> | Pluggable read-lock as a org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy implementation.
-| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mode where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
+| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-changed - (only for file component) idempotent-changed is for using a idempotentRepository and changed as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-rename - (only for file component) idempotent-rename is for using a idempotentRepository and rename as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mo
de where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
| readLockCheckInterval | lock | 1000 | long | Interval in millis 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. Notice: For FTP the default readLockCheckInterval is 5000. The readLockTimeout value must be higher than readLockCheckInterval but a rule of thumb is to have a timeout that is at least 2 or more times higher than the readLockCheckInterval. This is needed to ensure that amble time is allowed for the read lock process to try to grab the lock before the timeout was hit.
| readLockDeleteOrphanLockFiles | lock | true | boolean | Whether or not read lock with marker files should upon startup delete any orphan read lock files which may have been left on the file system if Camel was not properly shutdown (such as a JVM crash). If turning this option to false then any orphaned lock file will cause Camel to not attempt to pickup that file this could also be due another node is concurrently reading files from the same shared directory.
| readLockLoggingLevel | lock | WARN | LoggingLevel | 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.
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/components/camel-ftp/src/main/docs/sftp-component.adoc
----------------------------------------------------------------------
diff --git a/components/camel-ftp/src/main/docs/sftp-component.adoc b/components/camel-ftp/src/main/docs/sftp-component.adoc
index e5d9e56..fcd9fb3 100644
--- a/components/camel-ftp/src/main/docs/sftp-component.adoc
+++ b/components/camel-ftp/src/main/docs/sftp-component.adoc
@@ -110,7 +110,7 @@ The SFTP component supports 112 endpoint options which are listed below:
| minDepth | filter | | int | The 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.
| move | filter | | String | Expression (such as Simple Language) used to dynamically set the filename when moving it after processing. To move files into a .done subdirectory just enter .done.
| exclusiveReadLockStrategy | lock | | GenericFileExclusiveReadLockStrategy<T> | Pluggable read-lock as a org.apache.camel.component.file.GenericFileExclusiveReadLockStrategy implementation.
-| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mode where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
+| readLock | lock | | String | Used by consumer to only poll the files if it has exclusive read-lock on the file (i.e. 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: none - No read lock is in use 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 - Changed is using file length/modification timestamp to detect whether the file is currently being copied or not. 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. fileLock - is for using java.nio.channels.FileLock. This option is not avail for the FTP component. This approach should be avoided when acces
sing a remote file system via a mount/share unless that file system supports distributed file locks. rename - rename is for using a try to rename the file as a test if we can get exclusive read-lock. idempotent - (only for file component) idempotent is for using a idempotentRepository as the read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-changed - (only for file component) idempotent-changed is for using a idempotentRepository and changed as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. idempotent-rename - (only for file component) idempotent-rename is for using a idempotentRepository and rename as the combined read-lock. This allows to use read locks that supports clustering if the idempotent repository implementation supports that. Notice: The various read locks is not all suited to work in clustered mo
de where concurrent consumers on different nodes is competing for the same files on a shared file system. The markerFile using a close to atomic operation to create the empty marker file but its not guaranteed to work in a cluster. The fileLock may work better but then the file system need to support distributed file locks and so on. Using the idempotent read lock can support clustering if the idempotent repository supports clustering such as Hazelcast Component or Infinispan.
| readLockCheckInterval | lock | 1000 | long | Interval in millis 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. Notice: For FTP the default readLockCheckInterval is 5000. The readLockTimeout value must be higher than readLockCheckInterval but a rule of thumb is to have a timeout that is at least 2 or more times higher than the readLockCheckInterval. This is needed to ensure that amble time is allowed for the read lock process to try to grab the lock before the timeout was hit.
| readLockDeleteOrphanLockFiles | lock | true | boolean | Whether or not read lock with marker files should upon startup delete any orphan read lock files which may have been left on the file system if Camel was not properly shutdown (such as a JVM crash). If turning this option to false then any orphaned lock file will cause Camel to not attempt to pickup that file this could also be due another node is concurrently reading files from the same shared directory.
| readLockLoggingLevel | lock | WARN | LoggingLevel | 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.
http://git-wip-us.apache.org/repos/asf/camel/blob/10c2e35f/platforms/spring-boot/spring-boot-dm/camel-spring-boot-dependencies/pom.xml
----------------------------------------------------------------------
diff --git a/platforms/spring-boot/spring-boot-dm/camel-spring-boot-dependencies/pom.xml b/platforms/spring-boot/spring-boot-dm/camel-spring-boot-dependencies/pom.xml
index f94ee06..e8bffa9 100644
--- a/platforms/spring-boot/spring-boot-dm/camel-spring-boot-dependencies/pom.xml
+++ b/platforms/spring-boot/spring-boot-dm/camel-spring-boot-dependencies/pom.xml
@@ -2580,97 +2580,97 @@
<dependency>
<groupId>org.apache.cxf.services.sts</groupId>
<artifactId>cxf-services-sts-core</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf.services.ws-discovery</groupId>
<artifactId>cxf-services-ws-discovery-api</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-core</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-bindings-soap</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-bindings-xml</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-databinding-jaxb</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxrs</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-simple</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-management</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-jms</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-local</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-addr</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-mex</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-policy</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-rm</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-ws-security</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-wsdl</artifactId>
- <version>3.1.7</version>
+ <version>3.1.8</version>
</dependency>
<dependency>
<groupId>org.apache.ftpserver</groupId>