L.S.,

In my experience, with the current version of Camel, this can probably be
accomplished by creating your
own org.apache.camel.component.file.GenericFileProcessStrategy and plugging
that into the file endpoint.  I've used that to avoid processing large XML
files that were incomplete by looking at the contents before allowing the
file endpoint to pick up the file, so you can probably use it to look at a
database or a metadata file or something to figure out if the file has
changed as well.

You might also want to get in touch with the Camel commuity - perhaps
there's a way to add support for a configurable idempotent key value in the
endpoint or something like that in the future.

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/


On Tue, Oct 18, 2011 at 4:08 PM, Radomir Kadlec <[email protected]>wrote:

> Hello,
> I have to use Servicemix for *remote directory synchronization*.
> Files shall be transfered from the source directory structure to the
> destination place over Internet.
> I supposed the best way to implement this case is to use Camel *file* and
> *ftp* components.
>
> But I can not find any way to implement this functionality, because the old
> files must stay in their directories.
> They may not be deleted or moved and every file shall be transfered only
> once.
>
> The nearest way i found is to use the *indempotent repository* to memory
> all
> transfered files.
> But this repository contains *filenames only*. When the old file is
> replaced
> with new one with the same filename, the Camel file consumer doesn't choose
> it for transport any more.
> I miss the *file date in the key* in this indempotent repository.
>
> Or is there another way to synchronize two remote directories using
> Servicemix?
>
> Thanks for any tips.
> Radomir
>
> --
> View this message in context:
> http://servicemix.396122.n5.nabble.com/Servicemix-for-directory-synchronization-tp4913791p4913791.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>

Reply via email to