Thank you very much for your time and your help.
I indeed believe quite strongly that your solution works, though I still wonder how to delete the file in the second process (read/process/delete) when my output is not a file channel adapter (most of the time for me, a jms channel adapter).
However, I also believe that it looks quite complicated for something which could possibly be simpler if some of the complexity was hidden behind the file channel adater.
Imagine a configuration of the channel adapter where you can specify both:
- what you want to do before the file is processed (rename it with a suffix, move it to a different folder)
- what you want to do after the file is processed (delete the file, move it to a different folder).
Something which might look like the following (with definitely better attribute names):
where such strategies are given the File object and can manipulate it as needed. Most common strategies implementations (rename, delete, move-to) could be included within Spring Integration.
after-processed-strategy="customProcessedStrategy" ... />
or maybe this (maybe less flexible):
or maybe this:
<move-to value="/test/processing/" />
<rename-as expression="payload.name.concat(".processing")" />
The latter example would give a chance to the Channel Adapter to resend the files in the processing-directory with a header PossibleDuplicate set to true in case the JVM has crashed. But it doesn't give the option to rename the file or delete it.
These are just suggestions, but the big idea is to leave the complexity to the channel adapter and not to the user implementing his flow. In my opinion, it's ok to configure a flow by setting some attributes, but not modifying it entirely just to prevent duplicates or keeping track of the processed files.
What is your opinion on the subject? Is it worth discussing such a behaviour in a JIRA or not?
Sorry for the so long post and thanks for having read until the end