[CAMEL-17130] camel-file - Use NIO

[rnetuka]

Issue: https://issues.apache.org/jira/browse/CAMEL-17130

Changes:

1. There are simple Java IO -> NIO upgrades such as replace File usage with Path (in places it actually helps and doesn't make the code less readable)
2. FileConsumer - changed pollDirectory() and listFiles() methods to stream processing
3. FileResumeSet - completely rewritten to suit the stream processing above
4. FileUtils - some methods oveloads for Path for convenient usage

Notes:

• I've kept File as a class that is being transferred in an Exchange. I tried to replace it with Path, but run into problems with converters. If it makes sence, we can add this change in a next step
• the changes might not handle corner cases well, since for example File#getName() might return an empty string and Path#getFileName() return null in the same case. I suppose this doesn't pose much problem so I left it as it is.

[github-actions[bot]]

:warning: This PR changes Camel components and will be tested automatically.

[orpiske]

@rnetuka Nice one!

I'm wondering if it would make sense to plan for, in a future work, implement a better/more modern mechanism for watching for file notifications. That way, maybe it would not be necessary to poll all the time and, instead, use something like the WatchService. I believe this would be more resource efficient as well, as the JVM probably hooks to the native file system modification mechanism for each OS (i.e.: like inotify on Linux or something like that).

[bmarcj]

Great idea!

Using Java's NIO features exclusively opens the door to one day using something like the filesystem provider for s3 or minio e.g. https://github.com/Upplication/Amazon-S3-FileSystem-NIO2

[davsclaus]

@rnetuka Nice one!

I'm wondering if it would make sense to plan for, in a future work, implement a better/more modern mechanism for watching for file notifications. That way, maybe it would not be necessary to poll all the time and, instead, use something like the WatchService. I believe this would be more resource efficient as well, as the JVM probably hooks to the native file system modification mechanism for each OS (i.e.: like inotify on Linux or something like that).

There is already camel-file-watch

[davsclaus]

Make sure camel-ftp and camel-jsch keeps working after changing in camel-file

[orpiske]

@rnetuka Nice one! I'm wondering if it would make sense to plan for, in a future work, implement a better/more modern mechanism for watching for file notifications. That way, maybe it would not be necessary to poll all the time and, instead, use something like the WatchService. I believe this would be more resource efficient as well, as the JVM probably hooks to the native file system modification mechanism for each OS (i.e.: like inotify on Linux or something like that).

There is already camel-file-watch

Yeah, I know. My point is whether we can, maybe, consolidate code/features/etc where possible and opportunistically reduce duplicated feature set / code. It would make it easier to test and maintain, IMHO.

[davsclaus]

There are merge conflicts - can you update the PR thanks

[github-actions[bot]]

There are too many components to be tested in this PR, components were removed or the code needs a rebase: (302 likely to be tested)

[gitokus]

In FileConsumer filtering filenames before creating GenericFile would make big performance benefit when searching single file on network shares with thousand of files.

[oscerd]

@rnetuka can you please rebase?

[davsclaus]

closing old and outdated PRs